GitHub Actions YAML 文件需安装官方扩展才能获得语法高亮、校验和补全，卸载冲突的 YAML 扩展并重启 VSCode；on 事件不触发多因分支名拼写或缩进错误；uses 补全依赖 action.yml 公开可访问；“Unable to resolve action”是运行时问题，VSCode 无法检测。
GitHub Actions YAML 文件在 VSCode 里没语法高亮和校验？
默认安装 VSCode 后，.yml 或 .yaml 文件只是普通文本，不会识别 GitHub Actions 的结构语义，自然没有补全、错误提示或关键字高亮。这不是 VSCode 的缺陷，而是缺少对应语言支持。
真正起作用的是 GitHub Actions 官方提供的 VSCode 扩展，它注册了 github-actions 语言模式，让编辑器知道：on、jobs、steps 是顶层字段，uses 后面该接 action 路径，with 下的键名要匹配目标 action 的 inputs 定义。
- 必须卸载其他“YAML 支持”类扩展（比如 Red Hat YAML），它们常与 GitHub Actions 扩展冲突，导致语法检查失效
- 安装后需重启 VSCode，或手动通过
Ctrl+Shift+P→Change Language Mode→ 选GitHub Actions，否则文件可能仍被识别为纯 YAML - 如果工作流文件不在项目根目录（比如放在
.github/workflows/ci.yml），部分旧版扩展可能不自动激活，建议保持标准路径
为什么 on 下写 push: { branches: [main] } 没报错，但 CI 不触发？
VSCode 的语法检查只管 YAML 格式和 Actions 字段层级是否合法，不验证事件配置是否实际生效。常见陷阱是分支名拼写或缩进错误，例如把 main 写成 master（新仓库默认是 main），或 branches 缩进比 push 少一格。
-
on下的事件配置是字符串匹配，大小写敏感，main≠Main -
branches必须是列表，写成branches: main（没括号）会导致整个push配置被忽略，VSCode 不报错，但 GitHub 后端直接跳过该事件 - 私有仓库中，若启用了 branch protection rule，且未给 workflow 授权“绕过保护”，即使 YAML 正确，推送也可能被拦截——这层限制 VSCode 完全感知不到
如何让 uses 的 action 自动补全和参数提示？
VSCode 的 GitHub Actions 扩展能解析公开 action 的 action.yml（或 action.yaml），提取 inputs 定义并提供补全。但前提是 action 必须托管在 GitHub 上，且其 action.yml 可公开访问。
- 使用
uses: actions/checkout@v4这类官方 action 时，输入字段（如token、submodules）会实时提示类型和描述 - 用私有 repo 的 action（如
uses: myorg/my-action@main），除非该仓库设为 public，否则扩展无法拉取其action.yml，补全失效 - 本地路径引用（
uses: ./actions/my-build）完全无提示，扩展不支持本地文件系统扫描 - 版本号写
@v4比@main更稳：前者锁定 schema，后者随上游更新可能引入不兼容的 input 变更
CI 运行时报 Unable to resolve action，但 VSCode 里看着没问题？
这是最典型的“编辑器骗人”场景：VSCode 只校验语法和字段结构，不联网验证 action 是否真实存在、tag 是否有效、是否被删除或设为 private。报错发生在 GitHub Runner 拉取阶段，和本地编辑环境无关。
-
uses: some/action@v1.2.3在 VSCode 里一切正常，但若作者已删掉v1.2.3tag，就会触发该错误 - 组织内私有 action 若未授予对应仓库的
read:packages权限，也会报这个错，但权限问题 VSCode 无法检测 - 网络策略（如企业防火墙）拦截对
https://api.github.com的请求，同样表现为 “unable to resolve”，需查 runner 日志而非编辑器提示
所有这些，都依赖你盯着 GitHub Actions 的运行日志看，而不是只信 VSCode 里的绿钩子。语法对 ≠ 能跑通，这是最容易被忽略的断层。
