得票最高的功能终于来了，OpenTofu 开始内置代码检查

OpenTofu 发布了 1.13 版本，新增了一些函数，帮助模块作者在规划阶段解析更多表达式。当 count 或 for_each 使用的键原本会保持未知状态时，类型和值提示可以解除规划阻塞。规划器无需知道资源最终的全部属性，就能确定要创建多少个资源实例；这些属性可以继续保持未知，直至应用阶段。

OpenTofu 维护者 Martin Atkins 在一份 RFC 中提出了这项设计，并于 8 月合并了相关实现。在更早的一个 Issue 中，报告者 csar398 希望保留 YAML 输入，但当解码后的值用于控制 count 时，系统无法完成规划。yamldecode 可能返回多种不同类型，包括 null 值，因此，当输入未知时，规划器既无法确定类型，也无法保证其不为 null。Atkins 在解释这一限制时写道：“……这种情况实在太复杂，OpenTofu 无法自行自动推断。”

convert 函数可以将值转换为指定类型，从而让 yamldecode 的结果即使在 YAML 输入未知时，也具有已知的对象类型。对于条件资源，将这种转换与 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 和 file Provisioner 中移除了 Windows 远程管理（WinRM）支持，改变了 base64gzip 的输出字节，要求使用 macOS 13 Ventura 或更高版本，并且是最后一个提供官方 32 位构建的版本系列。它还新增了适用于 Windows ARM64 的软件包。现有 WinRM 配置需要进行迁移，而 base64gzip 背后的 Go 库变更即使产生的解压结果相同，也可能触发资源更新。

OpenTofu 缩短了开发周期，以便与 Go 的发布节奏保持一致，并将为 1.13.x 系列提供支持至 2027 年 8 月 1 日。该项目于 10 月 21 日发布了 1.13.2 版本。其中两项安全变更分别解决了连接到攻击者控制的 HTTP/2 服务器时，tofu init 可能过度占用 CPU 的问题，并过滤已遭入侵的中间证书。该补丁还修复了应用使用 Symbol Libraries 的已保存规划时出现的问题。

原文链接：https://www.infoq.com/news/2026/10/opentofu-1-13-unknown-values/