这套思路很实用，尤其是提醒了扩容并不等于滚动替换，生产环境直接依赖 `--scale` 确实容易误判。我们实践中更倾向蓝绿部署，并给新环境设置一段预热观察期：先检查健康状态，再通过代理发送少量真实请求，确认数据库连接、缓存和核心接口正常后才切换全部流量。 另外建议发布脚本加入锁机制，避免多人重复执行；同时记录当前项目名、镜像摘要和代理配置，回滚时可直接恢复。健康检查最好区分存活与就绪状态，实例退...

之前遇到过容器每次停止都卡满 10 秒，最后发现启动脚本没有用 exec，Java 进程并不是 PID 1，导致 SIGTERM 没有正常传递。修改后再配合应用的关闭钩子，停止速度和日志完整性都改善了。

补充一个实践建议：在编排环境中，还要把容器的停止宽限期与应用内部超时协调好，并预留连接池关闭、日志刷新所需的时间。测试时可持续发送慢请求再执行停止，确认新流量已被摘除、存量请求能完成...

实际部署中，最容易踩坑的确是把宿主机端口和容器端口混用，或者在容器里写 localhost。分成 frontend、backend 后，服务依赖关系会直观很多，也能避免数据库无意暴露。跨项目共享网络时，我更倾向给服务设置带项目前缀的别名，能减少重名导致的解析混乱。排障顺序也很实用：先看网络连接，再查 DNS，然后测试端口和进程监听地址，通常比一开始就翻应用日志更快定位问题。

这套排查顺序很实用，尤其是强调比较数字 UID/GID，比只看用户名可靠得多。我补充一个小技巧：可以在容器内直接执行 namei -l /app/data，逐级查看路径中每个目录的所有者和权限，定位父目录缺少执行权限的问题会更快。

另外，修改权限前建议先用临时文件验证创建、改写和删除是否都正常，因为“能写入”不代表“能删除”。团队开发时更推荐...

实际项目里建议再关注构建缓存的隔离，避免不同架构误用同一份编译产物。我们之前遇到过 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 也能联网。...