2. Terraform核心工作流
Terraform 的使用体验可以概括为一条“声明式闭环”：你写的是期望状态，Terraform 负责把它变成现实。理解这条闭环，关键要抓住四个命令、一个状态文件、一套 Provider 插件机制，以及一张由依赖关系构成的资源图。本节先讲清这些机制，再用一个跨云部署演练把它们串起来。
四个命令：init / plan / apply / destroy
terraform init 是初始化。它读取配置中的 required_providers，下载对应的 Provider 插件到工作目录下的 .terraform 目录，并初始化后端（backend）与模块。没有 init，后续命令无法识别 Provider 和模块来源。
terraform plan 是“预演”。它把配置声明的期望状态、状态文件中记录的实际状态、以及通过 Provider 查询到的真实资源三者做对比，输出一份执行计划：哪些资源要创建（+）、修改（~）、销毁（-）、重建（-/+）。plan 默认不改变任何真实资源，是审查变更、避免误操作的核心环节。
terraform apply 是“执行”。它默认会再跑一次 plan 并请求确认，然后按资源图的依赖顺序调用各 Provider 的 API，把变更落到真实云上，并把结果写回状态文件。
terraform destroy 是“回收”。它按依赖的逆序销毁当前配置管理的全部资源。生产环境应配合 -target 或审批流程谨慎使用。
状态文件：Terraform 的“记忆”
状态文件（默认 terraform.tfstate）记录的是“Terraform 认为的真实世界”。它保存每个资源的类型、名称、Provider、唯一 ID 以及关键属性。没有状态文件，Terraform 就无法知道某个云上资源是否已由自己创建，也就无法计算增量变更。
状态文件还承担依赖映射和元数据缓存的作用。它包含敏感信息（如初始密码、连接串），因此必须使用远端后端（如 S3 + DynamoDB 锁、Terraform Cloud、OSS 等）集中存储并开启加密与状态锁，避免多人同时 apply 造成状态损坏。团队协作中，永远不要把 tfstate 提交到 Git。
Provider 插件机制
Provider 是 Terraform 与具体云平台之间的适配层。Terraform 核心只负责解析配置、构建资源图、调度执行；真正调用阿里云、AWS、Azure API 的是各 Provider 插件。Provider 通过 gRPC 与核心进程通信，实现资源的 Create/Read/Update/Delete（CRUD）。
配置中通过 required_providers 声明来源与版本，通过 provider 块配置认证信息（如 region、access_key）。同一份配置可以同时声明多个 Provider，这正是跨云编排的基础。
资源图与依赖解析
Terraform 会把所有资源、变量、输出、模块解析成一张有向无环图（DAG）。依赖关系有两种来源：一是显式引用，例如 security_group_id = alicloud_security_group.sg.id；二是隐式依赖，Terraform 通过表达式自动推导。没有依赖关系的资源会被并行创建，从而加快 apply 速度。
依赖决定了执行顺序：创建时被依赖者先建，销毁时依赖者先删。理解资源图，就能预判 plan 中的顺序和并行度，也能解释“为什么某个资源总是最后才创建”。
首个跨云资源部署演练
下面用一个最小示例，在阿里云创建 VPC 与 ECS，同时在 AWS 创建 S3 桶，演示跨云编排。示例参数为教学假设值，实际执行需替换为你自己的凭证与地域。
terraform {
required_providers {
alicloud = { source = "aliyun/alicloud", version = "~> 1.200" }
aws = { source = "hashicorp/aws", version = "~> 5.0" }
}
}
provider "alicloud" { region = "cn-hangzhou" }
provider "aws" { region = "ap-southeast-1" }
resource "alicloud_vpc" "demo" {
vpc_name = "tf-demo-vpc"
cidr_block = "10.0.0.0/16"
}
resource "alicloud_vswitch" "demo" {
vpc_id = alicloud_vpc.demo.id
cidr_block = "10.0.1.0/24"
zone_id = "cn-hangzhou-i"
}
resource "aws_s3_bucket" "demo" {
bucket = "tf-demo-bucket-2024"
}
执行顺序如下：先 terraform init，终端会显示正在安装 alicloud 与 aws 两个 Provider；接着 terraform plan，输出中会看到 3 个资源待创建，其中 vswitch 因引用 vpc.id 而排在 vpc 之后，S3 桶与阿里云资源无依赖，可并行创建；确认无误后 terraform apply，输入 yes，Terraform 按图调度，最终输出 Apply complete! Resources: 3 added, 0 changed, 0 destroyed.。
验证方式：在阿里云控制台确认 VPC 与交换机已创建，在 AWS 控制台确认 S3 桶存在；再执行一次 terraform plan，若输出 No changes，说明状态文件与真实资源已一致，闭环成立。演练结束后用 terraform destroy 回收，观察销毁顺序与创建顺序相反。