VS Code 依赖 AWS Toolkit 插件、aws-cli（v2）、本地 ~/.aws/credentials 和 config 配置实现 AWS 部署；需验证插件连通性、正确配置 profile 与 region、使用 template.yaml 和相对路径 CodeUri，并通过 sam build/deploy 完成 Lambda 部署与调试。
VS Code 本身不直接部署 AWS 服务，它靠插件和 CLI 工具协同完成开发与部署闭环。核心路径是：AWS Toolkit 插件 + aws-cli（或 aws-sam-cli）+ 本地配置的 ~/.aws/credentials 和 ~/.aws/config。
安装并验证 AWS Toolkit 插件是否真正可用
插件装完不等于能用——它依赖底层 CLI 和权限配置。常见失败现象：点击“Deploy SAM application”无反应、资源列表为空、右下角状态栏显示 Failed to load AWS credentials。
- 确保已安装
aws-cli v2（运行aws --version输出应含aws-cli/2.x），v1不被 Toolkit 完全支持 - 运行
aws configure填入access key id、secret access key、region；不要跳过default output format，设为json - 检查
~/.aws/credentials文件中 profile 名是否与 VS Code 状态栏选中的 profile 一致（比如你用了[dev]，但 VS Code 选的是default） - 重启 VS Code，再看状态栏右下角是否显示 region 和 profile 名 —— 这才是插件已连通的信号
用 SAM 模板快速部署 Lambda 函数（最常用场景）
这是新手最容易上手、也最易踩坑的流程。Toolkit 提供图形化部署入口，但背后调用的是 sam build 和 sam deploy，任何一步失败都会卡在“Deploying…”不动。
- 项目根目录必须有
template.yaml（不是template.yml），且其中AWSTemplateFormatVersion字段不能缺失 - 函数代码路径（
CodeUri）必须是相对路径，比如./src，不能写成src/或绝对路径 - 首次部署前手动执行一次
sam build --use-container，可提前暴露 docker 权限、基础镜像拉取失败等问题 - 部署时若提示
No changes to deploy. Stack is up to date.，说明 CloudFormation 检测到模板无变更 —— 改动代码后需删掉.aws-sam目录再重试
Resources: HelloWorldFunction: Type: AWS::Serverless::Function Properties: CodeUri: ./src Handler: index.handler Runtime: nodejs18.x Timeout: 10调试 Lambda 函数：别只靠 console.log
Toolkit 支持本地调试，但默认行为容易误导：它启动的是模拟运行时（lambda-runtime），而非真实 Lambda 环境。很多冷启动逻辑、层加载、IAM 权限效果无法复现。
- 调试前务必在
launch.json中确认request是attach而非launch，否则会尝试新建进程而非连接本地 runtime - 事件模板（
Event.json）里不能包含 AWS 服务返回的元数据字段（如Records[*].eventSourceARN），否则本地 runtime 会报ValidationError - 如果函数依赖
aws-sdk的默认凭据链，调试时需显式传入credentials参数，否则可能因找不到 profile 报错 - 真要验证权限问题，唯一可靠方式是部署后用
aws lambda invoke手动触发，并查 CloudWatch Logs 中的REPORT行看实际执行时间与内存用量
真正卡住人的往往不是功能不会用，而是 credential 配置层级混乱（CLI / ide / Docker 容器各自读不同 profile）、SAM 构建缓存未清理、或误把本地调试当成环境等效。动手前先跑通 aws sts get-caller-identity 和 sam validate，比盲目点“Deploy”节省半小时。