vscode 通过 github actions 官方扩展实现工作流编写与校验，需正确安装插件、设置语言模式、遵循标准路径，并结合 act cli 本地模拟执行；侧边栏按钮仅跳转 github，无法替代真实运行环境。
VSCode 本身不运行 GitHub Actions，但能高效编写、校验和预览工作流逻辑——关键在装对插件、路径写对、本地验证不跳过。
安装 GitHub Actions 官方扩展并确认语言模式
VSCode 默认把 .yml 当普通 YAML 文件处理，不会识别 on、jobs、uses 等 Actions 特有字段。必须装 GitHub 官方发布的 GitHub Actions 扩展（发布者为 GitHub），它提供字段补全、悬停提示、uses 跳转和 schema 级校验。
装完后务必重启 VSCode，或手动执行 Ctrl+Shift+P → Change Language Mode → 选 GitHub Actions，否则文件可能仍被识别为纯 YAML。如果工作流不在标准路径（如 .github/workflows/ci.yml），扩展可能不自动激活，建议严格遵循该结构。
- 卸载冲突的 YAML 插件（比如 Red Hat YAML），它们会覆盖官方扩展的行为
- 私有 action（如
myorg/my-action@main）无法补全参数，因为扩展只读取公开仓库的action.yml -
uses: ./actions/my-build这类本地路径引用完全无提示，扩展不扫描本地文件系统
用 gha 代码片段快速生成合法骨架
手写 YAML 容易缩进错位或漏字段，导致 GitHub 后端静默忽略整个 on 配置。扩展内置了 gha 片段：在空的 .yml 文件中输入 gha + Tab，就能展开带 name、on、jobs 和基础 steps 的模板。
这个片段强制你从合法结构起步，避免常见陷阱，比如：branches: main（没括号）会被解析为字符串而非数组，push 下的 branches 缩进比 push 少一格会导致整个事件配置失效——VSCode 语法检查不报错，但 CI 就不触发。
- 片段生成的
on: [push, pull_request]是简写，等价于完整对象写法，可直接编辑 - 若需
pull_request_target这类高权限事件，得手动替换，扩展会校验拼写是否有效 - 分支名写
master而非main？新仓库默认是main，拼错就等于没配
用 act 在本地模拟执行并查看日志
“预览”不是看 YAML 渲染效果，而是验证 steps 是否真能跑通。VSCode 没有调试器，但你可以用 act CLI 在本地 Docker 中近似复现 runner 环境：
安装后，在 VSCode 集成终端里运行：act -j build（指定 job 名）或 act -W .github/workflows/test.yml（指定文件）。它会拉取对应基础镜像、挂载 workspace、逐条执行 run 和 uses 步骤，并输出实时日志。
- 必须提前启动
dockerd，act依赖 Docker；macOS 上用 Colima 或 Docker Desktop 均可 - 遇到
actions/github-script报GITHUB_TOKEN缺失？加-s GITHUB_TOKEN=xxx临时绕过（值任意，仅用于通过校验） -
act默认用nektos/act-environments-ubuntu:18.04，与 GitHub 官方ubuntu-latest（当前为 24.04）存在细微差异，比如预装软件版本 - 不支持
matrix全量展开或container内嵌services，这类复杂场景仍需推到 GitHub 查真实日志
别信“一键触发”，侧边栏按钮实际跳转 GitHub
GitHub Actions 官方插件在侧边栏提供 ▶ Run workflow 按钮，但它不真执行，而是打开浏览器跳转到 GitHub 对应页面，再由 GitHub runner 执行。所谓“预览日志”，也只是在 VSCode 里内联显示 GitHub API 拉取的远程日志流。
这意味着：你无法在本地调试 run 里的 shell 错误（比如 gawk 未安装），也无法验证 secrets 权限是否足够——这些都属于运行时问题，VSCode 插件和 act 都只能逼近，不能替代真实环境。
真正可控的预览，是把工作流拆成单元：用 shellcheck 验证脚本、用 docker run --rm -v $(pwd):/workspace ubuntu:24.04 bash -c "cd /workspace && npm test" 复现单步命令、再用 act 看整体流程衔接。复杂点永远在环境一致性上，而不是 YAML 写得漂不漂亮。
