给 Docker 容器日志加上限，从 Compose 配置到生效验证
容器标准输出持续增长，可能把宿主机磁盘占满。处理前先确认实际日志驱动，再给需要的服务配置轮转。下面面向 Docker Engine 与 Compose 管理的服务，不适用于直接套改 Kubernetes 日志配置。示例服务名 app 要换成自己的名称。
先看容器当前使用什么驱动
docker info --format '{{.LoggingDriver}}'
docker compose ps -q app
# 将下面的 CONTAINER_ID 替换为上一条返回的实际容器 ID
docker inspect --format '{{json .HostConfig.LogConfig}}' CONTAINER_ID第一条显示守护进程默认值，最后一条才是指定容器的实际配置；多副本应逐个检查。json-file 如果没有设置轮转上限，日志可持续增长。Docker 官方也推荐在没有特定兼容需求时考虑自带轮转的 local 驱动；已有日志采集系统时，切换前先确认它支持该驱动。
在现有 Compose 服务中合并配置
图：日志轮转配置按容器生效，示例保留文件数包含当前文件；修改后应重建目标容器并核验实际设置。
以下只是需要新增的片段，必须合并到原来的服务定义，保留已有 image、volumes、environment 等设置，不要用片段覆盖完整文件。先备份原配置，再合并下方的 YAML 片段。为了保留复制时的缩进，下面用 Bash 命令打印片段；它只输出文本，不写入文件。可在 Bash 中运行后，将 services 到 max-file 的输出合并到现有配置：
cat <<'YAML' services: app: logging: driver: "json-file" options: max-size: "10m" max-file: "3" YAML
max-size 控制单个日志文件的轮转阈值，max-file 控制保留文件数量，后者需要配合前者使用。这是每个容器的策略，不是整个项目共享 30 MB；还应为元数据、其他容器和应用自己的日志预留空间。轮转会淘汰较早的记录，需要长期审计时应先配置合适的外部留存方案。
验证配置，再安排重建
docker compose config --quiet
校验通过不代表运行中的容器已经改变。日志配置在创建容器时确定，单纯 restart 不能让旧容器采用新设置。重建会替换容器并造成服务中断，容器可写层的数据也不会自动保留。执行前核实业务数据已放在正确挂载的卷或目录中、备份可用，并安排允许中断的时间。
在原项目目录、使用原来的 Compose 文件组合和环境配置，确认当前镜像已在本地且无需构建后，再对目标服务执行：
docker compose up -d --no-deps --force-recreate --no-build --pull never app
这里不启动依赖服务，也不拉取或构建新镜像，减少把日志调整与版本升级混在一起的风险。若项目依赖构建或镜像尚未就绪，应先按原部署流程准备。不要为省事运行 down -v，它会涉及卷删除。
从新容器核验，而非只看配置文件
重新运行第一节的 ps 和 inspect，检查新容器确实采用预期驱动及两个上限，然后查看启动状态、健康接口和最近日志：
docker compose ps app docker compose logs --tail 50 app
通过 Docker 的日志接口读取记录，不要用外部脚本直接删除或截断 Docker 管理的日志文件。应用写到容器内部文件、挂载卷中的日志不受这项配置控制，需要单独设置轮转。最后继续观察磁盘趋势，并确认日志采集端仍能收到新记录。
