Terraform init 失败主因是云厂商认证未配全及插件源配置错误，需显式声明 provider 源、设置插件缓存路径与完整凭证，并注意各云平台资源参数差异、状态后端锁机制及 destroy 时的隐式依赖问题。
terraform init 总是失败：认证和插件路径是关键
云厂商认证没配对，terraform init 就会卡在插件下载或报 plugin not found。不是网络问题，而是 Terraform 默认从官方 registry 拉插件，但国内访问不稳定，且部分云厂商（如阿里云、腾讯云）插件已不托管在官方仓库。
- 先确认你用的是哪个云——比如阿里云要用
alibaba/alicloud，不是hashicorp/alicloud（后者已废弃） - 在
providers.tf里显式声明源地址：terraform { required_providers { alicloud = { source = "alibaba/alicloud" version = "~> 1.200" } } } - 如果公司有私有 registry 或离线环境，必须配
plugin_cache_dir+provider_installation块，否则每次init都重下 - 环境变量别只设
ALICLOUD_ACCESS_KEY，漏了ALICLOUD_SECRET_KEY或ALICLOUD_REGION，init虽不报错，但后续plan一定崩
aws_instance 和 alicloud_instance 的参数命名差异大得离谱
写完 AWS 的配置想套用到阿里云？别试。表面都是“创建一台 ECS”，但字段名、必填项、默认值全不一样，硬改容易漏掉隐性约束。
-
aws_instance用ami，alicloud_instance用image_id；前者支持ami-0abc123这种 ID，后者必须是镜像名称（如ubuntu_22_04_x64_20G_alibase_20230815.vhd）或 ID（但格式不同） - 安全组：AWS 是
security_groups = ["sg-xxx"]，阿里云是security_groups = ["sg-xxx"]看似一样，但阿里云要求该安全组必须和实例在同一个 VPC 内，否则apply时静默失败（日志只报InvalidSecurityGroupId.NotFound） - 磁盘类型：AWS 用
root_block_device控制，阿里云用system_disk_category（cloud_efficiency/cloud_ssd），且不支持直接指定 IOPS，得靠类型间接控制
state 文件锁不住，多人协作时 terraform apply 报错 lock failed
本地文件系统存 terraform.tfstate 是单机玩具模式。一上团队，没后端状态存储，apply 不是覆盖就是冲突，锁机制形同虚设。
- 别用
local后端，哪怕只是临时测试——至少用s3（AWS）、oss（阿里云）或cos（腾讯云），它们天然支持 DynamoDB / TableStore / CKafka 做状态锁 - 配置
backend时，bucket名必须全局唯一，且提前建好；key建议带项目+环境前缀，比如prod/network/vpc.tfstate，不然所有人共用一个文件，plan都可能看错状态 - 如果用 NFS 或共享目录模拟远程后端，Terraform 不认它为可锁后端，
apply会跳过锁检查，出事没人兜底
为什么 terraform destroy 有时删不干净资源？
不是 Terraform 失效，而是云平台侧存在隐式依赖或异步销毁逻辑。比如删除 VPC 前没清空其中的 NAT 网关，阿里云会返回成功，但 NAT 网关实际还在后台跑着，下次 apply 就报冲突。
- 先手动检查云控制台——重点看“正在释放中”“待删除”这类状态，Terraform 不感知这些中间态
- 某些资源（如阿里云 SLB 的监听、后端服务器组）必须显式定义为独立
resource，不能全塞进alicloud_slb块里，否则destroy时只删 SLB 实例，不删关联配置 - 跨账号或 RAM 角色权限不足时，
destroy可能静默跳过部分资源（尤其日志服务、KMS 密钥等），建议加-auto-approve前先跑一次plan -destroy确认范围
云端资源的生命周期管理，从来不是“写完代码就完事”。最麻烦的永远是那些没出现在 .tf 文件里、但真实存在的隐式状态——比如云厂商自动创建的默认安全组规则、VPC 流日志对象、甚至某个被遗忘的子网路由表条目。这些不会报错，但会让下一次 apply 在深夜三点突然失败。
