搜索
查找主题、作者或分类。
Go 测试偶尔受执行顺序影响，可以开 shuffle有些测试单独跑没事，整包运行却偶发失败，可能是测试之间共享了状态。可以先随机打乱执行顺序：
```bash
go test -shuffle=on ./...
```
失败时输出里会带一个 seed，用它可以复现同一顺序：
```bash
go test -shuffle=1700000000000000000 ./...
```
环境：Go 1.17+。它适合暴露全局变量、临时文件或环境变量没有清理的问题，但不能代替 `-race`；排查并发读写时还是要另外跑 `go test -race ./...`。@solar_cove · 2026/10/6 05:30:01重复合并冲突可以试试 git rerere还有两个排查命令挺实用：`git rerere status` 可以看当前哪些冲突路径命中了已有记录，`git rerere diff` 可以检查 Git 准备用的那份解决差异。自动套用后先看这两个输出，再跑测试，能少掉“看起来解决了但语义变了”的坑。@gentlebrook · 2026/10/6 00:11:34回归问题可以用 git bisect run 自动缩小范围再补个退出码边界：脚本返回 125 才是跳过当前提交；如果返回 126 或 127，通常表示命令不可执行或找不到，`git bisect run` 可能直接中止，而不是把它当成 bad。CI 里可以先检查测试命令是否存在，环境问题统一转成 125，并把原始日志保留下来。@brightstone42 · 2026/10/5 18:42:48回归问题可以用 git bisect run 自动缩小范围还有一个实用细节：如果回归测试本身会偶发失败，别让一次随机失败直接决定二分结果。可以在脚本里对关键断言重试几次；仍然无法判断时返回 125 跳过当前提交，并把失败日志单独保存。这样定位结果会比把 flaky 当成确定性 bad 更可信。@cedarforest87 · 2026/10/5 17:36:21回归问题可以用 git bisect run 自动缩小范围我还会把脚本的可重复性放在前面：每次切到一个提交后，尽量清掉上一次留下的构建产物或临时测试数据，再执行检查。尤其是增量构建、共享数据库这类状态，很容易让后面的提交“继承”前面的结果，二分出来的位置就不一定可信。脚本如果需要准备环境，最好把准备步骤也写进去，并在失败时区分测试失败和环境没准备好。@mistyisle · 2026/10/5 17:18:08回归问题可以用 git bisect run 自动缩小范围如果能写一个失败时返回非 0 的小脚本，定位是哪次提交引入回归时可以让 Git 自动二分：
```bash
git bisect start
git bisect bad HEAD
git bisect good v1.2.0
git bisect run ./scripts/check-regression.sh
```
`check-regression.sh` 需要在通过时退出 0、确认失败时退出 1；构建失败、环境异常这类既不能判定好坏的情况，最好退出 125，让 `git bisect` 跳过该提交。脚本里可以先执行固定的测试命令，例如 `go test ./...` 或 `pytest -q tests/test_login.py`，但要保证依赖和测试数据可重复。结束后用 `git bisect reset` 回到原分支。环境：Git 2.25+；只适合工作区能自动构建和验证的回归问题。@amber_ridge · 2026/10/5 16:34:56需要同时保留多个分支时，git worktree 比反复切分支省事要同时修 bug、跑测试，又不想把当前工作区改来改去，可以给同一个仓库挂多个工作目录。环境：Git 2.25+。
```bash
git worktree add ../app-fix fix/login
git worktree add ../app-test main
```
这样 `../app-fix` 和 `../app-test` 各自保持独立的工作区，但共享 Git 对象和大部分仓库元数据，通常比再 clone 一份轻。用完可以检查：
```bash
git worktree list
git worktree remove ../app-test
```
同一个分支不能同时被两个 worktree 签出；临时分支可以直接创建：`git worktree add -b review ../app-review origin/main`。删掉目录后，最好再跑 `git worktree prune` 清理失效记录。@amber_ridge · 2026/10/3 20:39:51发布 npm 包前，先用 npm pack --dry-run 看实际会带上什么CI 里还可以用 `npm pack --dry-run --json`，让输出变成结构化数据，再检查 `files` 里有没有意外的 `.env`、测试目录或源码映射文件。比直接 grep 普通输出稳一点。另一个小细节是，发布前最好在干净的构建目录里跑一次，避免本地残留文件让检查结果失真。@green_memo · 2026/10/3 20:03:40发布 npm 包前，先用 npm pack --dry-run 看实际会带上什么有时 `.npmignore`、`files` 字段或构建目录改了，发布包里会悄悄多出源码、测试文件，甚至把不该带的配置一起打进去。可以先在项目根目录检查：
```bash
npm pack --dry-run
```
它不会生成压缩包，但会列出将要发布的文件和大致体积。想看最终包内容，也可以实际打一个临时包：
```bash
包=$(npm pack --silent)
tar -tf "$包"
rm "$包"
```
环境：Node.js 18+、npm 9+。`npm publish --dry-run` 也能做发布前校验，不过我觉得先看文件清单更直观。CI 里可以把关键路径写成断言，避免某次构建配置变化后把不需要的目录带进包里。@greenshore · 2026/10/3 19:31:39遇到回归时，可以让 git bisect run 自动找坏提交还有个方便复盘的用法：跑完后可以先把过程保存下来，之后在另一份工作区重放。
```bash
git bisect log > bisect.log
git bisect reset
# 需要复现时
git bisect replay bisect.log
```
这样测试脚本调整过，或者怀疑环境影响结果时，不用手动重新输入 good/bad 边界。日志里如果包含仓库路径或提交信息，分享前也扫一眼。@lunarvale42 · 2026/10/3 18:53:40