beego 日志按天切分与自动清理需同时设置 daily=true 和 maxdays 为正整数，否则不生效；maxdays 基于文件 mtime 判断，受系统操作影响；v1/v2 版本导入路径不同，不可混用；异步日志下清理可能延迟。
Beego 的 core/logs 模块原生支持按天切分和自动清理，但必须显式启用 daily 模式并正确设置 maxdays，否则日志文件不会滚动也不会删除。
启用 daily 切分需同时配置两个关键参数
Beego 日志的「按天切分」不是默认行为，即使你用了 file 提供器，也得手动打开开关。核心是这两个配置项必须一起出现：
-
daily设为true（默认就是true，但显式写出来更安全） -
maxdays设为一个正整数（比如30），它才真正触发清理逻辑
如果只设 daily=true 而不设 maxdays，日志每天会新建文件，但旧文件永远堆积；如果只设 maxdays=30 但 daily=false，那根本不会按天生成新文件，maxdays 就没意义。
典型配置示例（在 conf/app.conf 或代码中）：
logs.SetLogger(logs.AdapterFile, `{"filename":"logs/app.log","daily":true,"maxdays":30}`)
maxdays 清理机制实际依赖文件修改时间
maxdays 不是按日志内容里的时间戳判断，而是读取操作系统中文件的 mtime（最后修改时间）。这意味着：
- 如果你用
cp或rsync复制日志文件，mtime会被更新，可能导致本该删的文件被保留 - 手动
touch旧日志文件会干扰清理，让它“变年轻” - 日志归档后未及时关闭写入句柄（比如进程未正常退出），可能让当天日志文件的
mtime停滞，影响后续判断
所以生产环境建议避免对日志目录做任意文件操作，确保 Beego 进程能完整控制日志生命周期。
注意 Beego v1 和 v2 的配置路径差异
Beego v2（当前活跃版本）的 logs 模块已独立为 github.com/beego/beego/v2/core/logs，而 v1 是 github.com/astaxie/beego/logs。两者配置结构一致，但导入路径不同，混用会导致：
- 编译报错：
undefined: logs.SetLogger - 运行时 panic：
panic: logger not registered
检查方式很简单：看 go.mod 里是否含 github.com/beego/beego/v2。如果是，就别 import astaxie/beego 相关包；反之亦然。
异步日志下 maxdays 可能延迟生效
如果你调用了 logs.Async(1e4) 开启异步写入，maxdays 的清理动作仍由主线程在每次写日志前检查，但实际删除时机取决于日志写入频率。低流量服务可能隔几小时才触发一次清理扫描。
这不是 bug，是设计权衡：避免高频检查磁盘 I/O。若需严格准时（比如每天凌晨 2 点清），应改用外部定时任务（如 cron + find logs/ -name "app.*.log" -mtime +30 -delete），而不是依赖 Beego 内置逻辑。
