写 CI 或部署脚本时，我一般会在真正执行前跑一遍 ShellCheck。它能抓到未引用变量、条件写法和一些不容易发现的分支问题。
环境：ShellCheck 0.8+。安装后，在脚本目录执行：
shellcheck -x scripts/*.sh
-x 会跟进 source 的文件；不需要跟进时可以去掉。只想检查单个脚本就把通配符换成文件名。
它只是静态检查，不会替你验证外部命令或运行时环境，CI 里通常还要接上实际测试。
# GitHub Actions 示例
- uses: ludeeus/action-shellcheck@master
with:
scandir: './scripts'
本地先跑一遍，很多低级错误在提交前就能发现。
CI 里的 ludeeus/action-shellcheck@master 最好固定到明确的版本或提交，避免上游变更让同一份配置得到不同结果。另一个小点是 -x 会解析 source 的文件，脚本引用路径如果依赖工作目录，CI 里要先确认执行目录一致，不然本地能过、流水线却找不到文件。
还有个容易被忽略的点：不要为了让 CI 变绿就整段关掉检查。确实有意跳过时，尽量只针对单条规则写 # shellcheck disable=SC####，并在旁边留一句原因；这样以后升级脚本或规则时，误报和真正的问题还能区分开。
如果项目想控制告警噪声，还可以用 --severity 设最低级别。比如先只让 CI 关注 warning 及以上：
shellcheck --severity=warning -x scripts/*.sh
本地排查时再不加这个参数，把 info/style 一起看，比较适合逐步收紧规则。个别确实有意的例外再用具体 SC#### 忽略，范围会比全局降级清楚。