补充一点：排查时最好同时记录容器的 OOMKilled 状态、宿主机内核日志和 cgroup 指标，单看 docker stats 很容易遗漏瞬时峰值。线上设置限制前，也要确认应用自身的内存策略，例如 JVM 堆上限、缓存容量和工作进程数，否则容器额度过紧可能导致频繁 OOM。对于数据库和低延迟服务，我更倾向于禁用或严格限制 Swap，并预留安全余量；普通后台任务则可以保留少量 Swap，应对短时...

这套排查思路很实用，尤其是强调不能看到 EPERM 就直接认定为 Seccomp。实际处理时，我会先用 strace 锁定失败调用，再结合 auditd 或内核日志确认拦截来源，避免误改 Capability 或文件权限。用 unconfined 做对照也很有效，但确实只适合隔离环境。建议自定义策略同时记录放行原因、适用镜像版本和验证用例，升级 Docker、内核或切换架构后重新回归，这样后续维护...

补充一个实操经验：排查时可以记录两次 cpu.stat 的差值，而不是只看累计值，再用节流时间增量除以采样间隔，更容易判断慢请求时段是否发生集中节流。压测也建议同时采集吞吐量、P95/P99、运行队列和 GC 暂停，避免“提高限额后恰好流量下降”造成误判。 另外，若服务有多个工作线程，0.5 核这类配额可能出现短时间并行运行、随后在周期内被节流的现象，因此平均 ...

这份排查思路很实用，尤其是把可写层、日志和 volume 分开判断，能避免一上来就执行 prune 误删资源。补充一点：排查日志时最好同时确认应用自身是否配置了文件轮转，否则即使限制了 json-file，容器内的业务日志仍可能持续膨胀。线上设置配额前，也建议先在同存储驱动、同文件系统的测试节点验证，并记录容器 SIZE、磁盘容量和 inode 的增长趋势。遇到已删除文件仍占空间时，优先让进程重新...

排查思路很实用，尤其是先比时间戳和 UTC，能避免一上来就改容器配置。我之前还遇到过 Compose 已修改 TZ，但只执行 restart，旧容器仍沿用原环境变量，重新创建后才生效。建议验证时同时关注应用进程的启动参数和数据库会话时区，因为容器里的 date 正常，并不代表运行时一定一致。生产环境统一存 UTC、日志带偏移量确实更稳，定时任务也最好安排一次跨重启测试，避免部署后才发现触发时间不对...

这份排查思路很实用，尤其是先区分“网络不通”还是“只有 DNS 异常”，能避免一上来就换公共 DNS。补充一个经验：遇到偶发超时时，可以分别指定 UDP 和 TCP 查询，并多次测试，排除 UDP 53 被拦截或响应包过大导致回退失败。

另外，修改 Compose 或 daemon.json 后，最好重新创建容器再验证，旧容器未必会自动获取新配置...

这份排查思路很实用，尤其是“先找第一个非 CACHED 步骤”，比直接清缓存有效得多。我之前遇到过本地正常、CI 每次重装依赖，最后发现临时 Runner 没有恢复 registry 缓存，而且构建编号作为 ARG 放在依赖安装之前，导致缓存键持续变化。调整 Dockerfile 顺序并补齐 cache-from、cache-to 后，命中率明显改善。建议流水线固定输出提交 SHA、平台、b...

排查顺序很实用，尤其是先看网络归属和服务监听，能避免一上来就重启 Docker。补充一个容易忽略的点：精简镜像里可能没有 ping、ss 或 nc，可以临时启动一个加入同网络的调试容器，用 curl、dig 等工具验证 DNS 和端口。另外，遇到容器重建后偶发断连，还应检查应用是否缓存旧 IP，以及连接池能否重新解析服务名。生产环境尽量把共享网络、别名和依赖关系写进 Compose，临时 netw...

这个排查顺序很实用，尤其是先看宿主机、再核对 docker inspect，能避免在容器里反复改文件却找不到根因。我之前就遇到过相对路径解析错误，Compose 从脚本目录启动后，实际挂载的并不是预期文件。

补充一个习惯：启动前可用 test -f /opt/app/config.yml 做校验，失败就直接终...

排查顺序很实用，尤其是同时检查磁盘容量和 inode，很多时候只看 df -h 确实容易漏掉问题。补充一点：处理残留挂载前，最好先记录 findmnt 输出和相关层路径，并确认业务容器已停止，避免误卸载仍在使用的 merged 目录。迁移 Docker 数据目录时，也要注意保留文件属主、权限、硬链接和扩展属性，复制完成后先用非关键...