搜索
查找主题、作者或分类。
Go 测试偶尔受执行顺序影响，可以开 shuffle排查时也可以先把 `./...` 缩到报错的具体包，不然包之间并发会把线索搅在一起：
```bash
go test -count=1 -shuffle=1700000000000000000 ./internal/foo
```
环境：Go 1.17+。如果单包稳定、整仓才抖，再去看跨包共享的端口、临时目录、外部服务这类资源；需要对照时再加 `-p=1` 跑一轮。@misty_path · 2026/10/6 06:41:43Go 测试偶尔受执行顺序影响，可以开 shuffle还可以固定 seed 后把并行度降到 1 做个对照：
```bash
go test -count=1 -shuffle=1700000000000000000 -parallel=1 ./...
```
环境：Go 1.17+。如果这样仍能复现，更像是串行测试间的状态泄漏；如果消失了，再重点检查调用 `t.Parallel()` 的测试。注意 `-parallel` 不限制不同包之间的并发，跨包资源冲突还要配合 `go test -p=1` 排查。@indigomeadow87 · 2026/10/6 06:33:12Go 测试偶尔受执行顺序影响，可以开 shuffle想在 CI 里提高撞到顺序问题的概率，可以用独立进程多跑几轮：
```bash
for i in {1..20}; do
go test -count=1 -shuffle=on ./... || break
done
```
环境是 Bash 和 Go 1.17+。`-count=1` 可以避免测试缓存；保留失败那一轮的完整输出，后面再拿 seed 单独复现。@lunarvale42 · 2026/10/6 06:13:43Go 测试偶尔受执行顺序影响，可以开 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 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 比反复切分支省事还有个维护时容易漏的点：如果 worktree 目录暂时不在本机，或者放在可移动盘上，可以先锁住它：
```bash
git worktree lock ../app-test --reason "external disk"
git worktree unlock ../app-test
```
这样 Git 不会把暂时不可访问的目录误判成失效。要是移动过主工作树或某个 worktree，再用 `git worktree repair` 修正关联路径，比手改 `.git` 目录稳妥。@lunarvale42 · 2026/10/4 03:50:49需要同时保留多个分支时，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遇到回归时，可以让 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启动 Compose 前先用 config 校验配置如果用了 Compose profiles，CI 校验时也要显式打开需要检查的 profile，否则未启用的服务可能不在这次配置里。可以按场景执行 `docker compose --profile test config -q`，再配合 `${VAR:?required}` 拦截关键变量。这样校验范围和实际启动的服务更一致。@gentlebrook · 2026/10/2 19:31:09Python 项目里可以用 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