max_files只控制最多保留的历史日志文件数量，不控制单个文件大小；单个文件切分由file_size决定，建议设为1MB～5MB，并确保配置位于channels.file.driver_options内。
File驱动的max_files到底控制什么
它不控制单个日志文件大小，只控制「最多保留几个历史日志文件」。比如设为30，当第31个日志轮转产生时，最老的那一个会被删掉。真正决定单个文件何时切分的是file_size（默认2097152，即2MB）。
常见错误现象：磁盘突然爆满，但max_files明明设了30——其实是file_size太小，导致每分钟都在生成新文件，30个很快堆满；或者file_size太大（比如设成104857600），单个文件涨到100MB还不切，直接撑爆分区。
-
file_size建议值：1MB～5MB之间，视日志密度调整；高并发写日志场景优先取下限 -
max_files不是越大越好，需结合日志保留周期算：比如每天产生10个文件，要留7天就设70，留30天就设300 - ThinkPHP 6.0+ 的
log.file_size单位是字节，别误填"2M"这种字符串，会静默失效
为什么max_files有时完全不生效
因为File驱动的日志轮转依赖「当前日志文件是否超过file_size」触发。如果应用长期低流量，单个日志文件始终没写满，就不会生成新文件，max_files自然无从裁剪。
更隐蔽的问题是：日志目录权限不对，或磁盘已只读，轮转时删旧文件失败，但框架不报错，只是默默跳过——结果就是日志越积越多，max_files形同虚设。
立即学习“PHP免费学习笔记（深入）”；
- 检查日志目录是否可写：
ls -ld runtime/log/，确保Web进程用户（如www-data）有写+执行权限 - 确认磁盘未满且非只读：
df -h和mount | grep " $(df . | tail -1 | awk '{print $1}') " - 手动触发一次轮转测试：
touch runtime/log/20240601.log && echo "test" >> runtime/log/20240601.log，再看是否生成20240601.log.1
ThinkPHP 6.x 中配置max_files的正确位置
它不在config/log.php的顶层，而是嵌套在channels.daily或channels.file的driver_options里。填错层级会导致配置被忽略。
错误写法：'max_files' => 30 直接写在log.php数组第一层；正确写法必须进具体channel的driver_options。
// config/log.php
return [
'default' => 'file',
'channels' => [
'file' => [
'type' => 'File',
'path' => __DIR__ . '/../runtime/log/',
'level' => 'info',
'driver_options' => [
'file_size' => 2097152, // 2MB
'max_files' => 30,
],
],
],
];
- ThinkPHP 5.1用的是
log.file.max_files，6.x起统一归入driver_options - 若同时用了
daily通道，注意它默认按日期分割，max_files对其无效；要用file通道才能生效 - 修改后务必清空
runtime/cache/，否则配置可能被缓存
日志暴增时的紧急止损操作
发现磁盘快满，别先改配置——先停写、再清理、最后调参。硬切日志文件可能造成当前句柄丢失，导致后续日志丢失。
典型错误：直接rm -f runtime/log/*.log*，结果PHP进程还在往已删除的inode里写，磁盘空间不释放。
- 先临时禁用日志：
Log::close()或把log.level设为'off'再reload应用 - 查正在写日志的进程：
lsof +D runtime/log/ | grep deleted，对输出里的PID执行kill -USR1 {pid}（部分SAPI支持优雅重开文件） - 安全清理：
find runtime/log/ -name "*.log*" -mtime +7 -delete，避免删正在写的文件 - 确认空间释放后再启用日志，并同步调小
file_size、收紧level（比如从debug降到notice）
最易被忽略的一点：max_files只管数量，不管总大小。就算设了30，如果每个文件都飙到50MB，照样占满磁盘——所以file_size才是第一道闸门。
