OpenTofu 1.13 发布：内置代码检查，规划阶段可解析更多表达式
OpenTofu 发布了 1.13 版本，新增了一些函数，帮助模块作者在规划阶段解析更多表达式。当 count 或 for_each 使用的键原本会保持未知状态时，类型和值提示可以解除规划阻塞。规划器无需知道资源最终的全部属性，就能确定要创建多少个资源实例；这些属性可以继续保持未知，直至应用阶段。 OpenTofu 维
OpenTofu 1.13 版本已发布，新增若干函数，让模块作者在规划阶段能解析更多表达式。count 或 for_each遇到原本会保持未知状态的键时，类型和值提示可以解除规划阻塞。规划器不必掌握资源最终的全部属性，就能确定要创建多少个资源实例；这些属性可以继续未知，等到应用阶段再定。这项设计由 OpenTofu 维护者 Martin Atkins 在一份 RFC 中提出，相关实现已于 8 月合并。更早的一个 Issue 中，报告者 csar398 希望保留 YAML 输入，但解码后的值用于控制
count时，规划无法完成。yamldecode可能返回多种不同类型，null 值也在其中。所以输入未知时，规划器既定不了类型，也没法保证结果不为 null。Atkins 解释这一限制时写道：“……这种情况实在太复杂，OpenTofu 无法自行自动推断。”
convert函数能把值转换成指定类型，这样即便 YAML 输入未知，yamldecode的结果也会带有已知的对象类型。对于条件资源，把这种转换和assumenotnull搭配起来，基于值是否为 null 的count表达式就能解析为 0 或 1，对象内容则依旧未知。作者必须保证生成的 YAML 始终表示指定类型的对象，且永远不会是 null。如果某个规划阶段未知的值之后违反了这一保证，OpenTofu 会在应用阶段报错。
Terraform 在 1.15 版本中率先发布了同等convert函数。Atkins 后来在 OpenTofu 的一个 Issue 中写道：“Terraform 已经提供了同等功能，其语法与我在这里提出的方案完全相同。”于是该项目决定沿用与 Terraform 一致的设计。
实验性代码检查包含四项内置警告规则，其中包括core:unused-variable 和 core:count-instead-enabled。使用 tofu validate、tofu plan 或 tofu apply只要打开相应开关，就能借助-lint=all启用上述规则。项目维护者在代码检查提案里把这项功能称作呼声最高的需求；后续计划还包括自定义规则，以及覆盖范围更广的策略检查。TFLint 早已提供插件式静态分析，其中就有面向云服务商的检查项。
另有一项可选开启的实验性能力叫 Symbol Libraries，靠*.sym.hcl文件来共享函数与类型定义。库本身无法直接碰资源、数据源或提供商函数，不过调用方可以把资源值传给库函数。团队打算在 1.14 版本中让这项功能转为稳定。
1.13 版本从remote-exec 和 fileProvisioner 里撤掉了 Windows 远程管理（WinRM）支持，同时改变了base64gzip的输出字节数，并把系统门槛提到 macOS 13 Ventura 及以上；这一系列也是最后一个提供官方 32 位构建的版本线。此外新增了面向 Windows ARM64 的软件包。已有的 WinRM 配置需要迁移，而base64gzip底层 Go 库的改动即使解压出来的结果一样，也可能让资源触发更新。
为了跟 Go 的发布节奏对上，OpenTofu 压缩了开发周期，1.13.x 系列的支持期将延续到 2027 年 8 月 1 日。10 月 21 日该项目放出了 1.13.2 版本。两项安全改动分别处理了连上攻击者控制的 HTTP/2 服务器时tofu init可能大量占用 CPU 的问题，并对已遭入侵的中间证书做了过滤。这个补丁还修掉了使用 Symbol Libraries 的已保存规划在应用时出现的毛病。
