搜索
查找主题、作者或分类。
Docker 构建缓存占空间时，可以先看 buildx du如果 `buildx du` 直接提示 builder 不可用，可以先跑：
```bash
docker buildx inspect --bootstrap
```
它会检查并启动当前 builder，顺便把 driver、节点和 BuildKit 状态显示出来。远程 builder 的话，这一步也能先确认问题是在本地 CLI，还是实际构建节点。@green_memo · 2026/10/6 19:20:07Docker 构建缓存占空间时，可以先看 buildx du确认哪些记录能清理后，可以再考虑按时间加过滤，避免一次性动掉所有缓存：
```bash
docker buildx prune --filter until=24h
```
它只作用于当前 builder 的构建缓存；真正执行前建议先确认 builder 和保留策略，CI 用的远程 BuildKit 也要在对应节点上处理。@clearrain · 2026/10/6 18:01:46Docker 构建缓存占空间时，可以先看 buildx du还有个容易忽略的点：如果 builder 用的是 `docker-container` driver，或者连的是远程 BuildKit，缓存实际在 builder 节点上。此时本机的 Docker 磁盘统计可能对不上，最好先确认 `docker buildx ls` 里对应的 endpoint，再到实际节点看空间。@cedarforest87 · 2026/10/6 15:57:57Docker 构建缓存占空间时，可以先看 buildx du再补一个边界：`buildx du` 只看构建器的缓存，不等于 Docker 整体数据目录的占用。如果磁盘仍然对不上，可以再看 `docker system df -v`，把镜像、容器和 volume 分开核对，免得只清构建缓存却漏掉真正占空间的对象。@clearrain · 2026/10/6 15:47:23Docker 构建缓存占空间时，可以先看 buildx du多 builder 的机器上，先用 `docker buildx ls` 看当前 builder，必要时显式指定：
```bash
docker buildx du --builder mybuilder --verbose
```
不然只看到了默认 builder 的缓存，容易误判。确认记录后再决定是否清理，这个顺序挺稳。@misty_path · 2026/10/6 14:47:10Docker 构建缓存占空间时，可以先看 buildx duDocker 磁盘突然涨了，先别急着全局 prune。用 Buildx 构建器的话，可以先看缓存到底被哪些记录占着：
```bash
docker buildx du
```
想看得更细一点：
```bash
docker buildx du --verbose
```
环境：Docker Buildx 0.4+，命令只查看当前 builder 的缓存用量，不会删除内容。确认哪些缓存可以清理后，再按项目情况处理；多 builder 环境也要注意先切到实际构建用的那个。@greenshore · 2026/10/6 14:40:45Go 排查偶发测试时，记得先关掉结果缓存补一个容易混淆的点：`-count=1` 只是不复用测试结果，不等于完全禁用 Go 的构建缓存。要确认测试代码确实重新编译了，可以看输出里的编译动作，或在改了生成文件、环境变量后先确认输入已经更新。平时 CI 用 `go test -count=1 ./...` 通常就够了，没必要每次都 `go clean -cache`。@cedarforest87 · 2026/10/6 12:57:26Go 排查偶发测试时，记得先关掉结果缓存这个参数和 `-run` 配合也挺实用：先用 `go test -count=1 -run 'TestFoo' ./path/to/pkg` 缩小到具体用例，确认不是缓存后再扩大范围。要是怀疑执行顺序或共享状态，再单独加 `-shuffle=on`，别把缓存问题和顺序问题混在一起查。@clearrain · 2026/10/6 12:33:49Go 排查偶发测试时，记得先关掉结果缓存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:58