terraform refresh 已被弃用，推荐使用 terraform plan -refresh-only（≥1.5）检测漂移，或删状态后 import 重认领；因其不校验配置一致性、不触发修正逻辑、且无法安全集成CI/CD。
直接说结论：用 terraform refresh 不再推荐，正确做法是删掉状态里对应资源、再用 terraform import 重认领，或直接跑 terraform plan -refresh-only（Terraform ≥1.5）。
为什么 terraform refresh 被弃用了
这个命令在 Terraform 1.5 之前确实能强制拉取云端最新属性写回 state，但它有三个硬伤：
— 它不校验配置是否匹配实际资源，比如你 HCL 里写了 instance_type = "t3.micro"，但线上已被手动改成 t3.small，refresh 会默默把 state 改成 t3.small，下次 apply 反而会把它改回去，形成“来回震荡”；
— 它不能触发任何配置修正逻辑，对依赖关系、隐式属性（如 aws_memorydb_cluster 的 num_replicas_per_shard）完全无感；
— 它和 plan 分离，无法被 CI/CD 流水线安全集成——没人敢让一个不输出变更预览的命令直接改 state。
terraform plan -refresh-only 怎么用才不踩坑
这是当前最稳的漂移检测+同步方式，它只做一件事：比对 state 和真实云环境，生成“仅刷新”计划，不执行任何变更。
— 必须加 -refresh-only 参数，否则默认行为仍是“计划变更+创建”；
— 输出里出现 ~ 行（比如 ~ engine_version）代表配置与实际不一致，不是 bug，是 drift 报告；
— 如果只想看某个资源，用 -target=aws_rds_cluster.example 精准定位，避免全量扫描拖慢响应；
— 配合 -out=plan.tfplan 保存结果后，可用 terraform apply plan.tfplan 批量同步，但注意：这步会把 state 更新为云端值，相当于“接受漂移”，不是“修复漂移”。
真正修复漂移：先 import，再调整配置
当 plan -refresh-only 显示出不一致，说明配置已脱离现实。此时不能直接 apply，而要分两步：
— 先用 terraform import aws_rds_cluster.example cluster-abc123 把当前真实集群导入 state（ID 必须准确，错一位就导致 terraform 认为“要删旧建新”）；
— 再检查 terraform show 输出，对比哪些字段和你的 HCL 不符（比如 backup_retention_period 实际是 7，但代码里写的是 14）；
— 手动改 HCL 配置，使其与真实状态一致，或者反向修改云上配置（用控制台或 CLI），让两者对齐；
— 最后跑一次干净的 terraform plan，确认 no changes，才算完成闭环。
最容易被忽略的一点：drift 不是技术问题，而是协作信号。每次 plan -refresh-only 报出差异，都意味着有人绕过 IaC 直接操作了云控制台、CLI 或其他工具。与其反复 sync，不如在权限层堵住手动入口——比如给生产账号关掉 rds:ModifyDBCluster，只留 ReadOnlyAccess 权限。
