RollingFileAppender 配合 SizeAndTimeBasedRollingPolicy 是生产环境最稳妥做法，必须配置 maxFileSize、maxHistory、totalSizeCap 和 fileNamePattern 四个参数，缺一不可，且需挂载外部日志路径并验证轮转生效。
直接用 RollingFileAppender 配合 SizeAndTimeBasedRollingPolicy，这是生产环境最稳妥、最常用的做法。它能同时按时间和大小切分日志，自动清理过期文件，从源头控制磁盘占用。
核心配置项必须设全
只配 <fileNamePattern> 不够，以下四个参数缺一不可：
-
maxFileSize：单个日志文件上限，推荐50MB～100MB。太小会导致碎片多，太大则轮转慢、备份卡顿 -
maxHistory：保留多少天的日志，比如30表示只留最近 30 天的归档 -
totalSizeCap：所有日志总大小上限，如2GB或3GB。这个是防爆盘的最后一道闸门 -
fileNamePattern：命名规则必须含日期和序号，例如logs/app-%d{yyyy-MM-dd}.%i.log，否则同一天多个文件会冲突
避免轮转过程加重 I/O 压力
滚动本身不是“零开销”操作，不当配置反而引发磁盘写入尖峰：
- 关闭
immediateFlush="true"（Logback 默认开启），改用缓冲写入，减少系统调用次数 - 不要在 Logback 内做 gzip 压缩；
<compression>gzip</compression>会阻塞主线程。更稳妥的是交由logrotate异步处理 - 禁用
TimeBasedTriggeringPolicy单独搭配SizeBasedTriggeringPolicy，防止每秒检查文件大小带来额外负担
挂载路径与容器部署需同步管控
Java 应用日志不走 Docker stdout/stderr，所以 Docker 层面的 max-size 对它无效：
立即学习“Java免费学习笔记（深入）”；
- 务必把
logs/目录挂载到宿主机外部路径，例如-v /data/app-logs:/app/logs，且该路径不能在系统盘上 - Logback 中
<file>路径要指向挂载后的路径，比如<file>/app/logs/app.log</file></li> <li>禁止日志写在容器内部未挂载路径（如 <code>/app/logs
但没 -v 映射），这类日志随容器生命周期堆积，极易撑爆磁盘
上线前必须验证的两件事
配置写完不等于生效，得确认它真在起作用：
- 启动应用后，进
logs/目录，看是否生成了带日期的文件（如app-2026-08-06.0.log），并持续追加内容 - 手动用
dd if=/dev/zero of=app.log bs=1M count=120模拟大日志，观察是否会触发轮转、旧文件是否被删除、totalSizeCap是否拦截增长
