最有效解法是全局配置 daemon.json：必须成对设置 max-size（如"10m"）和 max-file（如"5"），并启用 mode:"non-blocking"，重启 Docker 后新容器自动继承轮转策略，防止日志无限增长撑爆磁盘。
Docker 容器日志默认不轮转，用的是 json-file 驱动，但不启用任何限制——日志会一直追加到单个文件，几小时就可能涨到几十 GB，直接撑爆 /var/lib/docker/containers/ 所在分区。
最有效、最稳妥的解法是全局配置默认轮转策略，让所有新容器自动继承，避免漏配、误配。
一、全局配置 daemon.json（推荐生产环境）
编辑 `/etc/docker/daemon.json`（不存在则新建），写入：{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "5",
"mode": "non-blocking"
}
}- max-size: "10m"：单个日志文件上限 10MB，兼顾可读性与 I/O 性能
- max-file: "5"：最多保留 5 个轮转文件（当前 + 4 个历史），总空间 ≤ 50MB/容器
- mode: "non-blocking"：当日志写满时，不阻塞应用线程，保障服务不卡死
保存后执行：
sudo systemctl daemon-reload && sudo systemctl restart docker
⚠️ 注意：该配置只对重启后新建的容器生效；已有运行中容器需重建（docker rm -f && docker run 或 docker-compose up -d）才应用新规则。
二、单容器覆盖配置（适合关键服务调优）
对日志量特别大或敏感的服务（如支付、风控），可在启动时单独设更严策略：-
使用
docker run：docker run -d \ --log-driver json-file \ --log-opt max-size=5m \ --log-opt max-file=10 \ --log-opt mode=non-blocking \ --name payment-service \ registry/payment:v2.8
-
使用
docker-compose.yml：services: payment: image: registry/payment:v2.8 logging: driver: "json-file" options: max-size: "5m" max-file: "10" mode: "non-blocking"修改后需
docker-compose up -d重建容器。
Java 接口排错助手下载在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
三、验证是否生效
别只信配置，要实测确认：-
查容器日志配置：
docker inspect myapp | grep -A 8 "LogConfig"
看输出中是否含
"max-size"和"max-file"字段。 -
查日志路径并登录宿主机检查：
docker inspect myapp | jq -r '.[].LogPath' # 进入对应目录，ls -lh 看是否有 .1、.2 等轮转文件
四、清理已膨胀的日志（止血）
配置前旧容器可能已生成 GB 级日志，它们**不会自动清理**，需手动处理：-
找出最大日志文件：
sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -hr | head -5
-
安全清空（不中断服务）：
sudo truncate -s 0 /var/lib/docker/containers/<container-id>/<container-id>-json.log
✅ 用
truncate，不要rm—— 否则 inode 不释放，磁盘空间仍被占用。
不复杂但容易忽略
