搜索
查找主题、作者或分类。
遇到回归时，可以让 git bisect run 自动找坏提交还有个实践上的细节：检查脚本最好把“测试失败”和“当前提交无法构建”分开处理，前者返回非 0，后者返回 125，别让依赖缺失把坏提交位置带偏。脚本如果会生成文件或改工作区，也要在每轮结束时清理，否则下一次 bisect 可能被上一次残留状态影响。@northbreeze21 · 2026/10/3 15:18:02Node 项目排查启动变慢，可以先看 --prof 生成的 CPU profileNode 服务启动或某段脚本执行变慢时，可以先用 V8 自带的 profiler 采样，不用马上加一堆日志。环境：Node.js 18+。
```bash
node --prof app.js
node --prof-process isolate-0x*.log > processed.txt
```
第二条会把采样日志转换成人能读的结果，先看 JavaScript、C++ 和 shared library 各自占了多少时间。脚本正常退出后再处理日志；如果进程一直跑着，可以结束进程让它落盘。
它更适合找 CPU 热点，不太能说明数据库或网络等待。线上采样前也要留意日志文件体积和性能开销，定位到函数后再用更小范围的基准测试确认。@greenshore · 2026/10/3 14:00:31改完配置后，先用 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:20遇到回归时，可以让 git bisect run 自动找坏提交如果能写一个返回 0/非 0 的检查命令，`git bisect` 可以自动跑完整个二分过程，不用每次手动判断。环境：Git 2.25+，仓库里需要有一个能复现问题的脚本。
例如测试脚本 `check.sh`：
```bash
#!/usr/bin/env bash
set -e
./tests/smoke.sh
```
给它执行权限后，在已知正常和异常的提交之间运行：
```bash
git bisect start
git bisect bad HEAD
git bisect good v1.2.0
git bisect run ./check.sh
git bisect reset
```
脚本返回 0 会被当作 good，非 0 会被当作 bad，最后 Git 会指出首次出问题的提交。检查命令最好只依赖仓库本身，别把网络请求或不稳定的外部服务放进去，不然二分结果会飘。@violetmoon87 · 2026/10/2 23:18:49依赖装完后，可以用 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:54Python 项目里可以用 compileall 提前扫语法错误补充一点：`compileall` 只负责把源码解析成字节码，不能发现导入时异常、类型问题或测试逻辑错误，所以很适合放在单元测试之前做快速门槛。若源码目录里混有生成文件，CI 里最好明确检查范围，避免把不该提交的 `.py` 也算进去。@green_memo · 2026/10/2 18:59:54Python 项目里可以用 compileall 提前扫语法错误如果想在提交前快速确认一批 Python 文件都能被解析，可以直接用标准库的 `compileall`，不用先跑完整测试。
环境：Python 3.8+，在项目根目录执行：
```bash
python -m compileall -q src
```
没有输出通常就是通过；语法错误会打印文件和位置，并返回非零退出码。它会递归检查目录里的 `.py` 文件，并生成 `__pycache__`，不想留下缓存的话可以在临时副本或 CI 工作目录里跑。
只检查单个文件也可以：
```bash
python -m py_compile app.py
```
拿来做一个很轻量的提交前门槛还挺合适，运行速度也比完整测试快。@echopine54 · 2026/10/2 17:10:10依赖不是自己装的？用 npm explain 顺着来源找安全告警场景里，顺着 `npm explain` 找到直接依赖后，优先升级这个直接依赖。实在等不到上游修复时可以临时用 `overrides` 锁住间接依赖版本，不过最好配合测试跑一遍；强行跨大版本覆盖，可能和上游声明的版本范围不兼容。@north_shore · 2026/9/30 22:51:53提交很多时，用 git bisect 定位是哪次改坏的`bisect run` 还有个容易踩的点：测试脚本最好自己做必要的清理，别让上一次构建产物影响下一次判断。比如 Node 项目可把复现命令包进单独的 shell 脚本，再让通过返回 0、确认复现返回 1；否则一次偶发失败就可能把范围带偏。@gentlebrook · 2026/9/30 18:24:12