Go应安全调用Terraform或开发自定义Provider：必须用terraform-exec库而非exec.Command，显式指定二进制路径并设context超时；状态须隔离至独立远程backend，禁止共用或手动解析.tfstate；扩展Terraform必须开发v2 SDK Provider，要求Go≥1.18且ResourceData非线程安全。
Go 本身不管理基础设施，它也不该去“学习如何用 Terraform 管理基础设施”——这是常见误解的起点。真正要做的，是让 Go 安全、可控地调用 Terraform，或开发 Terraform Provider。二者路径完全不同，选错就卡死在 demo 阶段。
别用 exec.Command 调用 terraform
硬编码 exec.Command("terraform", "apply") 看似简单，但生产环境里会立刻暴露问题：TerraformBinary 路径不可控、stderr 被吞掉、context 中断后锁残留、版本混用导致 plan/apply 不一致。
- 必须用官方维护的
github.com/hashicorp/terraform-exec库，不是自己拼命令 -
NewTerraform()初始化时，第一个参数是工作目录（/path/to/infra），第二个必须是显式路径（如/usr/local/bin/terraform），不能依赖exec.LookPath("terraform") - 每次执行前加
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Minute)，避免云 API 卡住整个 goroutine -
Apply()返回的*ApplyResult里有ExitCode和Stderr，得检查result.ExitCode != 0，不能只看err != nil
状态文件不能共用，也不能手动读写
多个微服务实例或并发执行共享同一个 terraform.tfstate，必然导致覆盖、锁冲突、漂移无法追溯。更危险的是，有人试图在 Go 里 json.Unmarshal 解析 state 文件来取 RDS 地址——这破坏 Terraform 的状态一致性语义，且 JSON schema 随版本变，极易 panic。
- 每个环境（dev/staging/prod）或每个租户，必须配独立远程 backend，比如 S3 + DynamoDB 锁表
- backend 配置通过
backend.tf或tfvars注入，绝不能硬编码在模块里 - 需要输出值（如
db_endpoint）时，调用tf.Output(ctx, "db_endpoint")，它返回的是map[string]*tfjson.OutputValue，需做类型断言：v.Value.(string) - 绝对不要用
os.ReadFile("terraform.tfstate")——这不是 Go 的数据结构，也不是你的缓存层
想扩展 Terraform？必须写 Provider，不是写脚本
如果目标是把内部系统（比如 CMDB、自建 K8s 控制面、私有存储网关）纳入 Terraform 统一编排，那唯一正路是开发自定义 Provider。用 go 写 CLI 工具去“模拟”资源创建，只会让 IaC 流水线越来越脆弱。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
github.com/hashicorp/terraform-plugin-sdk/v2，v1 已废弃，且要求 Go ≥ 1.18 - 所有可选字段必须声明为指针类型（
*string,*int64），否则Default和Optional: true失效 -
ResourceData不是线程安全的：不能在 goroutine 里直接d.Set("field", val)，也不能并发读d.Get("field") - Provider 入口必须调用
plugin.Serve(&plugin.ServeConfig{ProviderFunc: provider})，否则terraform init会卡住或报Failed to instantiate provider
真正难的不是写几行 tfexec.Apply()，而是把状态隔离、错误传播、并发控制、provider 生命周期这些边界条件全兜住。多数人卡在“能跑通”，但线上一压就崩——因为没处理 context 超时后的 cleanup，没校验 ExitCode 就发了 service discovery 事件，或者在 ReadContext 里忘了加 resp.Diagnostics.Append(err) 而是直接 panic。这些点不显眼，但决定了能不能上生产。
