这份排查顺序很实用，尤其是先关闭重启策略、保留日志和 inspect 信息，再处理根因，能避免盲目重建丢失现场。我补充一点：线上修改策略前最好记录容器原配置，并同步检查宿主机的 dmesg 或 journalctl，确认是否存在 OOM、磁盘或 Docker 守护进程异常。对于一次性任务，若误配 always，退出码为 0 也会循环启动，确实很容易被忽略。重要服务还可以结合日志轮转、重启次数...

排查思路很实用，尤其是按访问路径逐层测试，比直接重启 Docker 或清空规则稳妥得多。我之前遇到过防火墙重载后映射失效，最后发现 Docker 链虽然还在，但 FORWARD 中的跳转关系已经异常。补充一点：建议故障发生时先保存 iptables-save 和 nft list ruleset 的输出，再与正常状态做差异对比，同时记录各规则计数器。若使用 Compose，还应检查 ports 配...

排查时结合 PPID 持续采样很重要，只看一次 ps 容易把短暂的 Z 状态误判为堆积。我之前遇到过入口脚本未使用 exec，导致应用收不到 SIGTERM，停止时只能等到超时强杀。改为 exec 后，再配合 init: true，退出和回收都稳定了。建议修复后做几轮高频创建子进程与 docker stop 测试，同时监控进程数和停止耗时。若仍有僵尸进程增长，还要继续定位真正未调用 wait 的父...

排查顺序很实用，尤其是查看 pids.current、pids.max 和 pids.events，比单纯统计 ps 行数更容易确认是否真正触顶。实际处理中还可以顺手记录故障前后的线程数量与进程树，结合应用日志判断是瞬时并发过高，还是线程、子进程没有正常回收。对于 Java 或多进程任务，不建议一出现报错就把上限调得很大，可以先临时扩容恢复服务，再根据高峰基线和增长趋势设定合理余量。同时最好给 p...

这套流程很实用，尤其提醒了“修改全局配置后必须重建旧容器”，很多人重启 Docker 后发现日志仍在增长，问题往往就在这里。补充一个排查点：清理日志后如果磁盘空间没有释放，可以用 lsof +L1 检查是否还有进程占用已删除文件，避免误以为清理无效。

生产环境建议在 Compose 文件中显式配置 logging，减少不同宿主机默认设置不一致的问...

功能看起来比较集中，适合偶尔处理短视频的用户。不过“已解锁”版本来源不明，建议先用杀毒软件扫描安装包，并在沙盒或备用设备中测试，注意检查是否存在捆绑安装、异常联网和后台进程。涉及去水印及二创时，也要确认自己拥有素材使用权，避免侵权；重要原视频最好提前备份。压缩、转码后可重点对比画质、音画同步和文件体积，确认稳定再批量处理。

Profiles 用来管理本地辅助工具确实很顺手，核心服务默认启动，也能避免新成员漏传参数后项目跑不起来。实际落地时建议再封装一层 Makefile 或启动脚本，例如统一提供 dev、test、ops 等命令，减少大家手动拼接参数。另一个容易忽略的问题是项目名和数据卷隔离，多套环境同时运行时最好设置不同的 COMPOSE_PROJECT_NAME，否则容器名、网络或持久化数据可能互相影响。CI 中...

这份排查思路很实用，尤其是把“Compose 插值”和“容器内环境变量”分开说明，能避免不少误判。我之前就遇到过修改 .env 后直接 restart，结果容器仍使用旧配置的问题，最后通过 docker compose config 查看解析结果，再用 docker inspect 和容器内 env 逐层比对，才发现容器没有...

排查思路很实用，尤其是强调“后续层删除并不会缩小历史层”，这个点很容易被忽略。我之前遇到过一次镜像暴增，最后发现是 COPY 把本地测试报告和缓存目录一起带进去了。除了配置 .dockerignore，也建议在 CI 中保存 docker image history 结果，并设置体积增长阈值。多阶段构建完成后，还要实际启动容器验证证书、时区和动态库是否齐全，避免镜像变小了，运行环境却缺少必要依赖。...

这份排查顺序很实用，尤其是区分“配置文件已挂载”和“内核参数已生效”，很多问题都卡在这里。补充一点：修改 Compose 的 sysctls 后，最好用 docker compose up -d --force-recreate，不要只执行 restart。验证时也应直接读取 /proc/sys 对应节点，并结合 Netwo...