必须显式配置 driver: "json-file"，否则 logging options 如 max-size 和 max-file 不生效；所有 options 值必须为字符串（如 "10m"、"5"），且修改后需 docker compose down && up 才生效。
logging.driver 必须显式设为 "json-file"
Docker 默认用 json-file 驱动，但 Docker Compose 不会自动继承 daemon 级默认值——如果你不写 driver: "json-file"，它可能沿用 daemon 配置（不可控），也可能在某些 Compose 版本中 fallback 到空配置，导致 max-size 和 max-file 完全不生效。
常见错误现象：配置了 max-size 却发现日志照常暴涨，ls -lh /var/lib/docker/containers/*/ 下看到单个 -json.log 文件远超 10MB。
- 必须写全：
driver: "json-file"，不能省略或写成driver: json-file（没引号是 YAML 解析错误） - 该设置只对
json-file和local驱动有效；syslog、journald、fluentd等不响应这些参数 - 若你用的是旧版 Compose（v1.x），语法一致，但建议升级到 v2.20+ 以避免某些 options 解析 bug
options.max-size 和 max-file 的值必须是字符串
max-size: "10m" 和 max-file: "5" 中的引号不是可选的。YAML 会把无引号的 10m 当作未知标量，把 5 当作整数，而 Compose 期望这两个字段都是字符串类型——解析失败时静默忽略，不会报错，但轮转完全不触发。
单位推荐全小写："10m" ✅，"10M" ❌（部分 Docker 版本识别不稳定）；支持单位包括 b、k、m、g，例如 "100k"、"2g"。
-
max-size是单个日志文件大小上限，达到即切割（不是“平均”或“软限制”） -
max-file: "3"表示最多保留 3 个文件：当前-json.log+ 最多 2 个历史轮转文件（如-json.log.1、-json.log.2） - 轮转由 Docker daemon 执行，不是容器内进程，所以无需应用配合或重启容器进程
修改后必须重启服务才生效
日志驱动和 options 是容器启动时绑定的元数据，运行中无法热更新。改完 docker-compose.yml 后执行 docker compose up -d 不会重载日志配置——它只会重建容器。
正确做法是彻底 down 再 up：
docker compose down && docker compose up -d
常见误操作：只执行 docker compose restart 或 docker restart <container></container>，此时容器 PID 变了，但日志驱动仍沿用原配置，max-size 不起作用。
- 验证是否生效：进容器查
docker inspect <container> | jq '.HostConfig.LogConfig'</container>，确认Driver和Options字段已更新 - 检查实际日志路径：
docker inspect <container> | grep LogPath</container>，然后ls -lh看文件大小和数量 - 注意：全局
/etc/docker/daemon.json设置与 service 级logging配置冲突时，后者优先
别忽略轮转的实际磁盘占用逻辑
max-file: "5" 不代表最多占 5 × max-size 空间。Docker 轮转是“先写新、再删旧”，极端情况下（比如日志写入峰值瞬间打满磁盘），可能短暂出现 6 个文件并存——尤其是当磁盘 I/O 延迟高时，删除最老文件的动作滞后。
更关键的是：max-size 控制的是 JSON 日志文件本身，不包含容器内应用自己写的文件（如 /app/logs/app.log），那些得靠应用层日志库（Log4j、Winston 等）单独配置。
- 生产环境建议留出至少 20% 缓冲空间，比如目标日志盘总容量 50GB，按
"10m"×"5"= 50MB 设定，实际预留 10GB 以上防抖 - 如果日志量极大（如每秒千行），考虑换
local驱动（压缩 + 更低开销），但它的max-size行为略有差异：按压缩后大小计算 - 轮转不清理已删除但被进程占用的日志文件（即 “deleted” 状态文件），遇到磁盘满却
df显示正常时，记得lsof +L1检查
