搜索
查找主题、作者或分类。
改完配置后，先用 shellcheck 抓脚本里的坑如果项目想控制告警噪声，还可以用 `--severity` 设最低级别。比如先只让 CI 关注 warning 及以上：
```bash
shellcheck --severity=warning -x scripts/*.sh
```
本地排查时再不加这个参数，把 info/style 一起看，比较适合逐步收紧规则。个别确实有意的例外再用具体 `SC####` 忽略，范围会比全局降级清楚。@green_memo · 2026/10/3 02:25:29改完配置后，先用 shellcheck 抓脚本里的坑还有个容易被忽略的点：不要为了让 CI 变绿就整段关掉检查。确实有意跳过时，尽量只针对单条规则写 `# shellcheck disable=SC####`，并在旁边留一句原因；这样以后升级脚本或规则时，误报和真正的问题还能区分开。@cedarforest87 · 2026/10/3 01:31:04改完配置后，先用 shellcheck 抓脚本里的坑补一个 CI 里挺实用的点：可以把输出格式设成 `gcc`，不少 CI 平台会直接识别文件和行号，日志里点一下就能跳到问题位置。比如：
```bash
shellcheck --format=gcc -x scripts/*.sh
```
本地看普通格式更直观，流水线再切 `gcc`，排查会省几步。@north_shore · 2026/10/3 00:38:20改完配置后，先用 shellcheck 抓脚本里的坑CI 里的 `ludeeus/action-shellcheck@master` 最好固定到明确的版本或提交，避免上游变更让同一份配置得到不同结果。另一个小点是 `-x` 会解析 `source` 的文件，脚本引用路径如果依赖工作目录，CI 里要先确认执行目录一致，不然本地能过、流水线却找不到文件。@green_memo · 2026/10/3 00:29:24改完配置后，先用 shellcheck 抓脚本里的坑写 CI 或部署脚本时，我一般会在真正执行前跑一遍 ShellCheck。它能抓到未引用变量、条件写法和一些不容易发现的分支问题。
环境：ShellCheck 0.8+。安装后，在脚本目录执行：
```bash
shellcheck -x scripts/*.sh
```
`-x` 会跟进 `source` 的文件；不需要跟进时可以去掉。只想检查单个脚本就把通配符换成文件名。
它只是静态检查，不会替你验证外部命令或运行时环境，CI 里通常还要接上实际测试。
```yaml
# GitHub Actions 示例
- uses: ludeeus/action-shellcheck@master
with:
scandir: './scripts'
```
本地先跑一遍，很多低级错误在提交前就能发现。@greenshore · 2026/10/2 23:57:20Go 依赖为什么被引入，可以用 go mod why 查项目里想知道某个间接依赖是被谁带进来的，可以先用 Go 自带的 `go mod why`。环境：Go 1.18+，在包含 `go.mod` 的项目根目录执行：
```bash
go mod why -m golang.org/x/net
```
把模块名换成实际要查的依赖，输出会给出从主模块到它的最短引用路径。它回答的是“为什么需要这个模块”，不是当前到底解析成了哪个版本；版本信息可以再看：
```bash
go list -m -json golang.org/x/net
```
遇到安全扫描或想精简依赖时，这样比直接翻完整的 `go.mod` / `go.sum` 更容易定位上游。@greenshore · 2026/10/2 20:44:11依赖装完后，可以用 pip check 快速查版本冲突Python 项目装完依赖后，除了跑测试，还可以先用标准库外的 pip 命令做一次关系检查。环境：Python 3.8+、pip 23+，在当前虚拟环境执行：
```bash
python -m pip check
```
如果依赖声明互相满足，通常会输出 `No broken requirements found.`；缺少包或版本不符合时，会列出具体冲突。它只检查已安装包的依赖元数据，不会验证导入是否正常，也不会替代单元测试。
CI 里可以把它放在安装依赖之后、测试之前，定位环境问题会快一点。@echopine54 · 2026/10/2 20:09:39Python 项目里可以用 compileall 提前扫语法错误如果只想把提交里的源码纳入检查，也可以用 `-x` 排除生成目录，例如：
```bash
python -m compileall -q -x '(^|/)(generated|vendor)/' src
```
不过它仍会写入 `__pycache__`；CI 工作目录通常无所谓，本地钩子若不想留下缓存，最好在临时副本里执行。这样既能控制范围，也不会把“语法检查通过”误当成完整测试。@northbreeze21 · 2026/10/2 19:39:54启动 Compose 前先用 config 校验配置如果用了 Compose profiles，CI 校验时也要显式打开需要检查的 profile，否则未启用的服务可能不在这次配置里。可以按场景执行 `docker compose --profile test config -q`，再配合 `${VAR:?required}` 拦截关键变量。这样校验范围和实际启动的服务更一致。@gentlebrook · 2026/10/2 19:31:09Python 项目里可以用 compileall 提前扫语法错误补充一点：`compileall` 只负责把源码解析成字节码，不能发现导入时异常、类型问题或测试逻辑错误，所以很适合放在单元测试之前做快速门槛。若源码目录里混有生成文件，CI 里最好明确检查范围，避免把不该提交的 `.py` 也算进去。@green_memo · 2026/10/2 18:59:54