必须调用logs.SetLogger才能写入文件日志，仅修改app.conf的loglevel无效；需在beego.Run()前配置AdapterFile、开启SetLogFuncCall和Async，并确保logs目录存在且路径正确。
logs.SetLogger 必须调用，否则日志只输出到控制台，哪怕你改了 app.conf 里的 loglevel 也没用。
不写代码就看不到文件日志
Beego 默认日志行为是：仅输出到 console，且级别为 LevelDebug。想写入文件，必须在 main.go 中 beego.Run() 之前显式调用 logs.SetLogger —— 这步跳过，日志永远不会落地到磁盘。
-
conf/app.conf中的loglevel、logoutput等配置项对默认日志模块完全无效 - Beego v2 的日志模块路径是
github.com/beego/beego/v2/core/logs，导入错路径（比如用了astaxie/beego/logs）会导致编译失败或运行时 panic - 如果项目已启用
beego.BeeLogger全局实例（比如调用了beego.SetLogger），再调logs.SetLogger会覆盖它；建议统一用logs包，避免混用
最简可用配置示例
以下三行加进 main.go 初始化段（beego.Run() 前）即可生成 logs/app.log：
logs.SetLogger(logs.AdapterFile, `{"filename":"logs/app.log","daily":true,"maxdays":7}`)
logs.SetLogFuncCall(true)
logs.Async(1e4)
-
"daily":true和"maxdays":7必须同时存在，否则不会按天切分，也不会自动清理旧文件 -
logs.SetLogFuncCall(true)加上后，每条日志末尾会带[file.go:123]，方便定位问题源头 -
logs.Async(1e4)开启异步写入，避免高并发下日志阻塞 HTTP 响应；缓冲区设为 10000 是较稳妥的值
常见错误：日志写了但没内容 / 文件为空
典型现象是日志文件创建成功，但始终为空或只有几行。原因往往不是配置错，而是运行时环境问题：
- 相对路径
"logs/app.log"在 Docker 或 systemd 启动时，工作目录可能不是项目根目录 → 改用绝对路径，或启动前cd /path/to/project - 目录
logs/不存在，且进程无权自动创建 → 启动前手动mkdir -p logs，或在代码中加os.MkdirAll("logs", 0755) - 日志级别太高（如设了
logs.SetLevel(logs.LevelError)），而你只打Debug或Info→ 检查是否漏掉logs.SetLevel调用，或临时注释掉它测试
别指望访问日志自动出现
Beego 不像 Nginx 或 Gin 那样自带 access log。HTTP 请求/响应详情（方法、路径、状态码、耗时）必须自己用 beego.InsertFilter + FinishRouter 拦截器拼装记录——这个动作和基础日志配置是两回事，漏掉就不会有访问日志。
真正上线时，daily 和 maxdays 的清理逻辑依赖文件系统 mtime，任何外部 touch/cp 操作都可能让清理失效；不要在日志目录里做手工归档或备份。
