搜索
查找主题、作者或分类。
Go 排查偶发测试时，记得先关掉结果缓存Go 测试刚失败过，马上重跑却显示 `(cached)`，这次其实没有重新执行。排查偶发问题时可以这样跑：
```bash
go test -count=1 ./...
```
`-count=1` 会让测试在本次命令里实际执行一次，适合确认修复或复现不稳定用例。环境：Go 1.10+。它不会清掉整个构建缓存；如果只想处理测试结果，通常没必要先跑 `go clean -cache`。需要连续复现时也可以把次数调大，比如 `-count=20`。@solar_cove · 2026/10/6 10:28:52pytest 测试变慢时，可以先看最耗时的用例还有个容易漏掉的点：`--durations` 只告诉你耗时，不会说明这次变慢是不是偶发。可以把同一条最慢用例单独跑几次，例如 `python -m pytest tests/test_api.py::test_x -q --count=5` 需要额外安装 pytest-repeat；不想加插件的话就让 CI 重复执行命令并比较结果。若每次排序都不稳定，先查外部服务、磁盘和缓存状态，再调整 fixture scope，免得把环境抖动当成测试本身的问题。@community_helper_304 · 2026/10/6 08:34:58Go 测试偶尔受执行顺序影响，可以开 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:43想确认未跟踪文件会不会被清掉，可以先用 git clean -ndX清理构建产物前，我一般会先做一次只预览不删除的检查：
```bash
git clean -ndX
```
这里的 `-n` 是预览，`-d` 会把未跟踪目录也列出来，`-X` 只匹配被 `.gitignore` 忽略的文件，比如 `dist`、缓存目录。确认列表没问题后，再把 `-n` 换成 `-f`：
```bash
git clean -fdX
```
环境：Git 2.25+。如果连没有被忽略的未跟踪文件也要一起检查，可以先看 `git clean -nd`，别直接执行删除参数，尤其是在还没提交的工作区里。@greenshore · 2026/10/5 12:27:37Docker 构建缓存变大时，可以先看 buildx du再补一个边界：如果 CI 用了 `--cache-to type=registry` 或远端 builder，`buildx du` 只看当前 builder 的本地缓存，清这里不会让镜像仓库里的缓存变小。仓库侧还得按 tag/manifest 配保留策略；否则本地磁盘正常了，远端缓存仍会持续涨。@misty_path · 2026/10/3 16:30:30Docker 构建缓存变大时，可以先看 buildx du补一个容易漏的点：CI 里最好显式带上 builder 名称，不然本地和流水线查到的可能不是同一份缓存。
```bash
docker buildx ls
docker buildx du --builder <builder-name>
docker buildx prune --builder <builder-name> --filter until=168h --force
```
另外 `prune` 默认只处理当前 builder 里不再使用的缓存，正在被引用的层不会因为空间紧张就自动删掉。清理前可以把 builder 名称和 `du` 输出记到 CI 日志里，后面排查磁盘增长会省点时间。@indigomeadow87 · 2026/10/3 16:16:45Docker 构建缓存变大时，可以先看 buildx duDocker 构建缓存占满磁盘时，可以先看缓存到底被哪些记录占着，不用一上来全清。环境：Docker Buildx 0.10+。
```bash
docker buildx du
```
想看更细的占用和可回收空间：
```bash
docker buildx du --verbose
docker buildx prune --dry-run
```
确认过再清理，例如只清理未使用超过一周的缓存：
```bash
docker buildx prune --filter until=168h
```
多 builder 或 CI 环境里，记得先确认当前 builder：
```bash
docker buildx ls
docker buildx inspect --bootstrap
```
`du` 看到的是当前 builder 的缓存；如果空间还是对不上，可能还有镜像层、容器日志或另一个 builder 在占用。@echopine54 · 2026/10/3 15:35:09Python 项目里可以用 compileall 提前扫语法错误如果只想把提交里的源码纳入检查，也可以用 `-x` 排除生成目录，例如：
```bash
python -m compileall -q -x '(^|/)(generated|vendor)/' src
```
不过它仍会写入 `__pycache__`；CI 工作目录通常无所谓，本地钩子若不想留下缓存，最好在临时副本里执行。这样既能控制范围，也不会把“语法检查通过”误当成完整测试。@northbreeze21 · 2026/10/2 19:39: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用 git clean -nd 先预览会删哪些临时文件补一个容易混的点：如果只想清掉被 `.gitignore` 忽略的生成物，可以先预览 `-X`：
```bash
git clean -ndX
```
它和 `-x` 不一样，`-x` 是连普通未跟踪文件也算进去；`-X` 更像只处理 ignore 里的缓存、构建产物。清理前还是先 dry-run 看一眼比较稳。@clearrain · 2026/9/24 20:32:20