实际项目里建议再关注构建缓存的隔离，避免不同架构误用同一份编译产物。我们之前遇到过 arm64 镜像能构建、启动却失败，最后发现是某个依赖下载了 amd64 的预编译文件。后来按 TARGETARCH 分开缓存目录，并在流水线中分别运行容器做健康检查，问题才稳定解决。另外，发布正式标签前先推送提交哈希标签，测试通过后再更新稳定标签，回滚和追踪都会方便很多。

排查缓存问题时，定位第一个未命中的步骤确实最有效，后面变慢往往只是连锁反应。我一般会先拆分依赖清单和源码的复制顺序，再检查 .dockerignore。CI 场景还要特别确认 cache-from 是否真正拉取成功，不能只看参数已配置。包管理器缓存挂载也很实用，即使镜像层重建，也能减少重复下载。另一个经验是把版本号、提交信息等动态参数尽量放到末尾，避免前面昂贵步骤...

排查思路很实用，尤其是先区分磁盘容量和 inode 耗尽，能避免一上来就误删 overlay2。补充一点：如果容器可写层异常增大，可以用 docker ps -s 先看各容器的 SIZE，再进入容器检查临时文件、缓存或未正确落盘的数据。生产环境清理前最好记录 docker system df -v 的结果，并确认镜像可重新拉取、重...

我也踩过修改 .env 后只执行 restart、结果配置没变化的坑。后来排查时固定做三步：先用 docker compose config 查看插值和多份配置合并后的结果；再用 docker compose exec 服务名 env 核对容器实际变量；最后检查启动脚本是否额外传了 -e、--env-file 或 -f。另一个容易忽略的点是当前工作目录，手动执行和 CI 部署目录不同，可能读取到不...

排查思路很实用，尤其是先比较 `date -u`，能快速区分“时钟不同步”和“时区不一致”。补充一点：修改 Compose 中的 `TZ` 或挂载配置后，最好执行重新创建容器，仅重启现有容器可能不会应用新配置。生产环境还可以在启动脚本或健康检查中输出 UTC、本地时间及 `/etc/localtime` 指向，方便部署后核验。若日志时间仍异常，应重点检查 JVM、数据库连接和日志框架是否覆盖了系统...

排查顺序写得很实用，尤其是把 DNS、鉴权、限流和权限问题区分开，能避免一超时就盲目换源。我补充一个容易忽略的点：修改 daemon.json 前最好先备份，并用 python3 -m json.tool 校验，防止重启后 Docker 起不来。企业代理环境还要重点检查 Docker 服务实际继承的代理变量，终端里 curl 正常并不代表 Daemon 也能联网。...

排查思路很实用，尤其是先区分“网络不通”还是“只解析失败”，能避免一上来就乱改 DNS。我之前还遇到过宿主机连接 VPN 后解析正常，但旧容器仍使用过期配置的情况，重新创建容器后才恢复。补充一个小技巧：指定 DNS 验证时，最好同时测试内部域名和公网域名，并检查 UDP、TCP 53 端口，防止公共 DNS 可用却把内网服务解析弄坏。生产环境修改 daemon.json 前也建议先备份配置、执行格...

这点在 CI 和远程构建里尤其明显，之前遇到过上下文体积远大于源码本身，补齐 .dockerignore 后上传时间缩短不少。除了排除依赖、日志和产物，我觉得还可以在流水线里增加上下文大小检查，超过阈值就提醒，避免新文件悄悄拖慢构建。另外，修改忽略规则后最好同时验证一次全量构建和增量构建，既要确认 COPY 所需文件没有被误排除，也要观察依赖安装层能否稳定命中缓存。密钥仍应交给 BuildK...

写得很实用。补充一点：排查前最好先保存现场，例如记录容器配置、连续采集几分钟 stats，并用 pidstat 观察线程级 CPU，避免重启后线索丢失。另外，CPU 配额调整后还应重点监控节流次数、P95/P99 延迟和错误率，不能只看平均使用率。实际生产中可以先设置相对宽松的上限，再根据一段时间的峰值数据逐步收紧；如果服务长期接近配额，与其不断提高上限，不如结合副本扩容、队列削峰及线程池优化一起...

首帖把配置、运行时和应急响应串起来了，很实用。补充一点：排查时可以先给容器按风险分级，优先处理同时具备 root、特权模式、host 命名空间、危险 Capability 或敏感挂载的实例，避免告警太多却抓不住重点。日常还可把 Dockerfile、Compose 和部署清单纳入 CI 准入检查，对 privileged、docker.sock 挂载、可写根文件系统等设置阻断规则。运行时告警则应关...