把云资源变更交给 OpenTofu 前，我会先管好 state 和 plan

很多团队第一次把云资源写进代码时，最容易关注一条命令创建网络、实例和数据库。我会先把变更预览和状态管理跑顺，再谈自动化发布。OpenTofu 把云上资源写成可版本化的配置文件，并用一致的 write、plan、apply 流程留下证据。对于小团队，这比在控制台里靠记忆点按钮可靠得多。

原创示意图：小团队先提交配置，再生成 plan，经过评审后由带锁的 apply 更新云资源和 state。来源：Codex image generation

配置先进入评审

OpenTofu 官方入门文档把核心流程拆成 Write、Plan、Apply。配置文件描述目标状态，provider 对接云平台或其他服务 API，plan 告诉团队将创建、更新或销毁哪些对象，apply 才真正执行。落到协作里，每一次云资源变更都应先进入代码评审：变量名、模块边界、provider 版本、命名规则和标签策略都在同一个 pull request 里讨论。

这一步看似慢，实际能减少隐性成本。控制台修改往往只留下操作时间，配置修改还能解释原因。安全组端口、存储生命周期、DNS 记录和监控告警都写在仓库里，排查事故时能直接回到变更 diff。

plan 是上线前的共同语言

tofu plan 会读取已有远端对象的当前状态，把配置和 prior state 做比较，然后给出拟执行动作。官方文档也提醒，单独运行 plan 不会真正执行变更，适合在评审前验证影响范围。我的做法是把 plan 输出纳入 CI：每个基础设施 PR 都跑格式化、校验和 speculative plan，把新增、修改、删除的资源数量贴回评审页面。

需要更谨慎的环境可以使用 -out=FILE 保存计划，再交给后续 apply 使用。但这个文件可能包含完整配置、输入变量和敏感值，不能随手上传到普通日志。更稳妥的方式是只保留脱敏摘要，把详细 plan 放进受控 artifact，并设置过期时间。

state 要当成生产数据

OpenTofu 必须保存 state，用它映射真实资源和配置里的 resource instance。默认本地文件名是 terraform.tfstate，但官方建议团队场景把它放进能版本化、加密并安全共享的协作系统。state 决定下一次 plan 如何判断差异，也记录远端对象和配置之间的一对一关系。

我会避免人工编辑 state 文件。官方文档明确说，虽然 state 文件格式是 JSON，直接编辑并不推荐，应该优先使用 tofu state 这类 CLI 命令。凡是碰到 tofu import、tofu state rm、资源重命名，都应单独建变更单，并在 apply 后保存必要摘要，方便之后追踪。

锁和权限是底线

只要 backend 支持，OpenTofu 会在可能写入 state 的操作上自动加锁，避免多人同时写坏状态。官方 locking 文档还提醒，force-unlock 只能在确认自动解锁失败且目标是自己的锁时使用。流水线里也要写清楚：apply 只允许受保护分支触发，云凭证使用短期权限，生产环境要求人工批准，锁等待超时后直接失败，脚本里不偷偷加 -lock=false。

从低风险环境开始

推荐顺序是先把现有资源按模块分层，再把远端 state 和锁配置好；随后让 CI 在每个 PR 上跑 tofu fmt、tofu validate 和 tofu plan；最后再接入受控 apply。可以先从 DNS、对象存储、监控告警或测试环境开始。等团队习惯了 plan 摘要、state 备份和审批记录，再逐步覆盖网络、数据库和生产权限。

OpenTofu 是开源工具，近期 GitHub Releases 仍在持续发布 1.12.x 系列。真正值得投入的点不只在免费可用，更在它把云资源变更从临场操作变成可评审、可复跑、可追溯的工程流程。