写得很实用，尤其是“修改全局配置后必须重建旧容器”这一点，确实很容易被忽略。补充一个排查经验：如果日志文件看着不大，但磁盘空间仍未恢复，可以用 lsof +L1 查找已删除却仍被进程占用的文件。另外，重建容器前最好先导出或核对环境变量、端口映射、挂载目录和重启策略，避免只解决日志问题，却遗漏原有运行参数。生产环境还可以为日志目录单独设置磁盘告警，并结合容器数量估算...

功能整合得挺全面，磁力、网盘和短视频处理集中在一个应用里，日常使用确实方便。不过这类需要登录并通过第三方网盘分发的修改版，建议安装前先用安全工具查杀，留意权限申请，尽量别绑定常用手机号或重要账号。解析、去水印和素材去重也要注意平台规则及版权要求，只处理自己拥有授权的内容。最好先用备用设备测试下载速度、后台耗电和稳定性，并保留原版安装包，出现闪退或异常时方便回退。

这个排查顺序很实用，尤其是先分别测试 IP 和域名，能避免一开始就误改 DNS。补充一点：宿主机使用 systemd-resolved 时，容器里的上游地址可能在网络切换或 VPN 重连后失效，可以检查 `resolvectl status`，再对照容器中的 `/etc/resolv.conf`。另外，临时指定公共 DNS 虽然方便，但企业内网域名往往会因此解析失败，最好同时验证公网域名、内部域名...

这套排查顺序很实用，尤其是先保存规则、再结合计数器和抓包定位，能避免一上来清空规则导致故障扩大。补充一点：测试时可同时用 ss -lntp 确认宿主机端口占用，并用 curl -v 分别访问容器 IP、本机映射端口和宿主机外网地址。若只在防火墙重载后失效，建议重点核对 iptables 后端及 firewalld 配置，而不是长期...

这份排查思路很实用，尤其是强调要直接查看业务进程的限制，而不是只看容器内临时 shell 的 ulimit。实际排障时还可以把 FD 数量做成定时采样，例如每分钟记录一次，并与请求量、连接数同步对比，比较容易区分高峰期容量不足和持续泄漏。日志切割后也建议检查是否存在已删除但仍被占用的文件，这类问题很隐蔽。另一个细节是修改 Compose 的 ulimits 后应重新创建容器，再通过 /proc/目...

这份排查顺序很实用，尤其是先关闭重启策略、保留日志和 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，减少不同宿主机默认设置不一致的问...