改完 .github/workflows/*.yml 后，我一般先跑一遍 actionlint，能提前抓到表达式、字段和 job 配置的明显问题。
环境：actionlint 1.7+，Linux/macOS；项目根目录执行：
# 已下载 actionlint 二进制并放在 PATH 后
actionlint
# 只检查某个工作流
actionlint .github/workflows/ci.yml
它只静态检查，不会触发工作流，也不会改文件。要是仓库里用了自定义 action 或特殊表达式，仍然建议再看一次 Actions 的实际运行结果；但提交前先过这一关，通常比等 CI 返回更快。
这个适合放进提交前的本地检查。补充一点：actionlint 主要看 YAML、表达式和常见字段，权限配置或 action 本身的安全风险还得单独审；所以它通过了，也不等于工作流运行时一定没问题。
还可以顺手把它放到一个很轻的 CI job 里，只 checkout 后跑 actionlint，不用等依赖安装。这样工作流文件写错时，失败点会比测试 job 更早出来，排队时间也少一点。
本地想统一的话，用 pre-commit 包一层也挺合适；只是别把它当成替代 GitHub 实际运行结果就行。
MukiLv1#2 还可以顺手把它放到一个很轻的 CI job 里，只 checkout 后跑
actionlint，不用等依赖安装。这样工作流文件写错时，失败点会比测试 job 更早出来，排队时间也少一点。本地想统一的话，用
pre-commit包一层也挺合适；只是别把它当成替代 GitHub 实际运行结果就行。
再补一个容易忽略的点：本地只传某个 yml 路径时，其他工作流文件不会被扫到；放进 CI 的校验 job 里直接执行 actionlint，让它遍历 .github/workflows/ 更稳。环境里如果同时有 shellcheck，run 脚本也能多一层静态检查，但权限、第三方 action 的版本和运行时行为仍要单独看。