docker inspect 看不到 max-size 配置，是因为该配置仅对修改 daemon.json 后新创建的容器生效，运行中容器不会自动更新；若启动时显式指定 --log-opt 但遗漏 max-size，则其值为空；单位必须为小写（如"200m"），含空格、大写或无单位均导致解析失败；旧日志文件不会被自动清理，需手动处理。
docker inspect 看不到 max-size 配置？容器没重创建
配置写进 /etc/docker/daemon.json 后，只对新创建的容器生效。正在运行的容器不会自动继承新配置，docker inspect 查出来的 LogConfig 仍是旧值。
- 用
docker ps -a找出目标容器，确认它是否是修改配置后启动的 - 已运行容器必须先
docker stop && docker rm，再用docker run重新创建（或docker-compose down && up） - 检查是否误加了空格或引号：比如
"max-size": "200 m"（带空格）或"max-size": "'200m'"（多余单引号）都会导致解析失败，配置静默丢弃
max-size 值写成 200m 但实际日志还是超了？单位和格式要严格匹配
Docker 对 max-size 的单位解析很敏感，不支持缩写歧义或大小写混用。写成 200m 看似没问题，但以下情况会导致无效：
-
200M（大写 M）——Docker 只认小写k、m、g，大写会被忽略，退化为默认无限制 -
200 mb或200 MB（带空格或单位全称）——解析失败，整个log-opts被跳过 -
200（没单位）——Docker 当作字节数处理，即 200 字节，远小于预期，会频繁轮转但不报错 - 正确写法只有：
"max-size": "200m"（纯数字+小写单位，无空格）
日志文件还在涨，但 docker logs 查不到新内容？可能是日志驱动被覆盖了
容器启动时如果显式指定了 --log-driver 或 --log-opt，会完全覆盖 daemon.json 的全局配置。哪怕只加了一个 --log-opt，其他未指定的选项也会丢失。
- 检查容器启动命令或
docker inspect输出中的HostConfig.LogConfig.Type和HostConfig.LogConfig.Config - 若
Type是json-file但Config为空或只有部分字段，说明启动时用了--log-opt却漏写了max-size - 例如：
docker run --log-opt max-file=3 nginx→max-size不生效，因为没传
磁盘空间没释放，以为配置失效？其实是旧日志文件还占着 inode
即使新容器已按 max-size 轮转，宿主机上仍可能残留大量旧的 *-json.log 文件，尤其是 max-file 设置偏大（如设成 10）或之前没配过轮转时积累的“历史包袱”。
- 手动查：进入
/var/lib/docker/containers/，用du -sh *-json.log看真实占用 - 轮转只管“新增”，不管“存量”；旧文件不会被自动清理，除非触发轮转且数量超
max-file - 临时清空可用：
cat /dev/null > container-id-json.log（注意不是rm，否则空间不释放）
配置生效的关键不在“写没写”，而在“谁在用、怎么用、有没有残留”。max-size 是个安静的守门人——它只在新日志写入时起作用，既不清理过去，也不覆盖显式声明，更不接受模糊语法。
