一个经常被开发者提及的问题：能否在 VSCode 中“模拟运行” Terraform？答案是——不能，即使安装了最全面的插件也无法实现。这并非功能缺失，而是 Terraform 的执行模型本质上依赖 CLI 调用、provider RPC 通信以及 state 状态管理。插件仅提供语言服务（LSP），并不嵌入运行时环境。因此业内所谓的“模拟”，实际上是运用了一种巧妙变通——借助 local backend 与 null provider 构建出一个轻量、快速、无副作用的本地精简执行环境。

更直白地说：terraform plan 与 terraform apply 必须真实调用 CLI，并连接对应的 provider——即便只是 local 或 null 这样轻量的 provider。纯编辑器内部的沙盒式执行并不存在。所谓的“模拟”，本质上是通过最小化依赖、可控的 backend 配置以及轻量级 provider 来实现快速验证，而非跳过实际的执行环节。

为什么无法在 VSCode 里真正“模拟运行”

Terraform 的执行模型依赖三个阶段：plan（构建 graph 并生成 diff）、state 状态管理、以及 provider RPC 调用。VSCode 插件仅提供语言服务（LSP），并不嵌入运行时。所有“运行”操作实质上都是调用本地的 terraform 二进制文件，走的是 shell 子进程，而非插件内部的仿真机制。

• 插件所能做的极限是：hover 展示 resource "aws_instance" 的 schema、悬停时显示 count 参数提示、跳转至 module 定义位置——这些都属于静态分析，并非实际执行
• 点击 “Run Plan” 命令（如 Terraform: Plan）只是在集成终端里执行 terraform plan -out=tfplan，这与在外部终端手动敲命令完全等效
• 试图绕过 CLI 直接“模拟”会导致 state 状态不一致、provider 验证缺失、变量注入逻辑错乱——这会直接破坏基础设施即代码（IaC）的确定性与可靠性原则

借助 local backend 与 null provider 快速验证语法与流程

真正可行的“类模拟”方式，是转换思路而非硬闯——将远程依赖（AWS/Azure/GCP）替换为本地无副作用的 provider，配合 local backend，实现秒级 init/plan/apply 操作，且完全不触碰任何真实云资源。

• 在 main.tf 中声明：

  terraform {
    required_version = ">= 1.6.0"
    backend "local" {
      path = "terraform.tfstate"
    }
  }
  
  provider "null" {
    version = "~> 3.2.0"
  }

• 编写一个测试 resource：

  resource "null_resource" "example" {
    triggers = {
      timestamp = timestamp()
    }
  }

• 确保项目根目录下不存在 .terraform/ 文件夹，然后手动执行：terraform init → terraform plan → terraform apply -auto-approve
• VSCode 插件会实时解析这一过程：状态栏显示 Terraform v1.6.6，输出面板中 Terraform: Plan 命令直接触发，同时 plan 结果会高亮展示新增资源（以绿色标识）

VSCode 中哪些操作看似“模拟”，实则暗藏陷阱

不要被表面功能所迷惑。以下操作很容易被误认为是模拟执行，但其实际行为与限制必须清晰认知：

• Terraform: Validate 仅校验 HCL 语法和基础块结构，不会检查 provider 是否可用、变量是否可解析、source 模块路径是否存在——它不加载 provider plugin，因此 aws provider 缺失时也不会报错
• 保存时自动执行 terraform fmt 属于纯文本格式重排，不涉及任何执行逻辑。但如果 fmt 操作失败（例如路径配置错误 terraform.path），VSCode 不会弹出明确错误提示，仅在输出面板 Terraform 标签下刷出一行空白日志
• 模块跳转功能（Cmd+Click source = "./modules/vpc"）依赖 terraform init 后生成的 .terraform/modules/ 符号链接，若未执行过 init 则无法点击跳转——这并非插件问题，而是 Terraform 工作流本身的固有要求
• Hover 展示 aws_s3_bucket 参数文档的前提，是插件已成功加载对应的 provider schema。schema 加载发生在 terraform init 之后，且仅加载已声明的 provider——如果未编写 provider "aws" 块，则无法看到 AWS 相关文档

非标准文件名（如 .infra.tf）需手动绑定语言模式

VSCode 默认仅对 *.tf 和 *.tfvars 后缀启用 Terraform 语言服务。如果使用 backend.infra.tf 这类命名方式，即使文件内容全部是合法 HCL，插件也会将其视为纯文本处理——代码补全失效、格式化不触发、validate 命令不可用。

• 打开该文件，点击右下角语言标识（例如显示 Plain Text）
• 选择 “Configure File Association for '.infra.tf'…” → 输入 terraform → 回车确认
• 立即生效：状态栏变为 Terraform，右键菜单出现 Format Document，Cmd+Click module 开始支持跳转
• 此绑定为 workspace 级别，会写入 .vscode/settings.json 的 "files.associations" 字段，切勿遗漏

归根结底，Terraform 的“本地运行”并非真正的模拟，而是一种精简化的执行方式。VSCode 的真正价值在于让 init/plan/apply 这些真实的 CLI 操作变得更加可控、更加可观察——例如一键打开输出面板查看 plan 的差异对比，或通过鼠标悬停快速查询参数含义。然而，任何试图跳过 CLI 调用、幻想在编辑器内部“跑通”配置的想法，都会在 apply 阶段暴露问题。最高效的验证路径，始终是 null provider + local backend + 手动触发 CLI 命令这一组合。