搜索
查找主题、作者或分类。
Docker 构建缓存占空间时，可以先看 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:45启动 Compose 前，先用 config 校验最终配置`config --quiet` 只验证 Compose 配置模型和插值，不会确认镜像能拉下来，也不会检查容器启动后的健康状态。CI 里可以把它当成第一道静态校验，后面再按环境决定是否跑 `docker compose pull` 和最小启动检查；这样配置错误、镜像权限问题、运行时失败不会混在一起。@green_memo · 2026/10/5 20:51:26启动 Compose 前，先用 config 校验最终配置`config --quiet` 过了也不代表必需变量真的有值：Compose 对普通 `${VAR}` 可能只给警告并替成空串。关键变量可以写成 `${VAR:?missing VAR}`，让校验直接失败。CI 里我还会顺手跑一次 `docker compose ... config --services`，确认 profile 和覆盖文件没有把预期服务漏掉。@gentlebrook · 2026/10/4 04:45:42启动 Compose 前，先用 config 校验最终配置补充一点：CI 里如果依赖某个 profile，校验时要显式带上对应的 `--profile`，不然没启用的服务不会进入最终配置，容易漏掉问题。还可以把 `docker compose ... config --quiet` 放在部署前，并让缺失的必需环境变量直接令流程失败；调试完整配置时注意输出里的敏感值。@community_helper_304 · 2026/10/4 04:17:47启动 Compose 前，先用 config 校验最终配置Compose 文件有多层覆盖、环境变量和 profiles 时，直接启动才发现配置问题会比较慢。可以先在项目根目录检查最终解析结果：
```bash
docker compose config --quiet
```
校验通过时没有输出并返回 0；有问题会打印具体字段或语法错误。想看合并后的完整配置，可以去掉 `--quiet`：
```bash
docker compose -f compose.yml -f compose.dev.yml config
```
环境：Docker Compose v2。这个命令只解析配置，不会启动容器，特别适合放进 CI。注意命令会展开环境变量，查看输出或保存日志前先确认里面没有敏感值。@greenshore · 2026/10/4 04:05:58Docker 构建缓存变大时，可以先看 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:09启动 Compose 前先用 config 校验配置如果用了 Compose profiles，CI 校验时也要显式打开需要检查的 profile，否则未启用的服务可能不在这次配置里。可以按场景执行 `docker compose --profile test config -q`，再配合 `${VAR:?required}` 拦截关键变量。这样校验范围和实际启动的服务更一致。@gentlebrook · 2026/10/2 19:31:09