log.SetOutput不能直接接*os.File实现轮转，因标准文件不支持自动切换，需自定义io.Writer封装轮转逻辑，含大小监控、原子替换、并发锁及过期检测。
log.SetOutput 为什么不能直接接 *os.File 轮转？
因为 log.SetOutput 接收的是 io.Writer，而轮转需要在写入前判断文件大小或时间，标准 *os.File 不具备自动切换能力。直接传入一个固定文件句柄，日志永远只写进同一个文件，轮转逻辑必须自己控制写入时机和目标。
常见错误现象：调用 os.OpenFile 时用了 os.O_APPEND 但没关旧文件，导致 fd 泄露；或轮转后仍往旧 *os.File 写，新日志进了老文件。
- 轮转不是“换文件名”，而是“换 io.Writer 实例”
- 每次写日志前需检查是否触发轮转条件（大小/时间），是则先
Close()旧文件、再OpenFile()新文件、再更新log.SetOutput() - 必须加锁（
sync.Mutex），否则并发写日志时可能多个 goroutine 同时触发轮转，造成文件覆盖或 panic
用 io.MultiWriter 分流日志到文件 + 控制台是否可行？
可以，但不解决轮转问题 —— io.MultiWriter 只是把一份日志同时写进多个 io.Writer，它本身不感知文件生命周期。若其中一个 writer 是轮转中的文件，你仍得自己管理那个 writer 的切换。
典型使用场景：调试阶段既要看到终端输出，又要保留完整日志到磁盘，且磁盘部分需轮转。
立即学习“go语言免费学习笔记（深入）”；
- 分流本身无性能瓶颈，但轮转逻辑仍需独立实现
- 不要对
io.MultiWriter做Close()，它不持有底层资源；要关的是它内部每个*os.File - 示例中常误把
MultiWriter当作可轮转对象，结果只轮转了文件部分，控制台部分正常，但文件部分失效
logger := log.New(io.MultiWriter(fileWriter, os.Stdout), "", log.LstdFlags) // fileWriter 必须是封装好的、支持轮转的 io.Writer 类型，不是裸 *os.File
如何安全地实现按大小轮转（size-based rotation）？
核心是拦截每次写入，检查当前文件大小，超限时新建文件并重置计数器。不能依赖 os.Stat() 频繁查大小（有 syscall 开销），推荐在每次 Write() 后更新内存中记录的 size。
容易踩的坑：用 os.Stat().Size 判断是否轮转，但该值可能滞后（缓冲未刷盘）；或轮转时未同步更新内部 size 计数器，导致下一次写入立刻又触发轮转。
- 用自定义 struct 包裹
*os.File，实现io.Writer接口，并维护curSize int64 - 每次
Write(p []byte)后执行w.curSize += int64(len(p))，再判断是否 >=maxSize - 轮转函数内必须：
oldFile.Close()→newFile := os.OpenFile(...)→w.file = newFile→w.curSize = 0 - 注意 Windows 下重命名正在写的文件会失败，建议生成带时间戳的新文件名（如
app.log.202405201530），而非app.log.1
log.SetOutput 替换后，旧文件句柄何时关闭才安全？
必须在确认所有 goroutine 都不再写入旧 writer 后才能 Close()。由于 log.Logger 是无锁写入，替换 SetOutput 瞬间就生效，但正在执行的 logger.Print() 可能还在用旧 writer。
所以不能在轮转函数里直接 oldFile.Close()，而应延迟到「确保无进行中写入」之后 —— 最稳妥方式是：用 channel 或 sync.WaitGroup 协调，或更简单：让 writer 自己在 Write() 中检测是否已被弃用。
- 推荐方案：自定义 writer 内嵌
atomic.Bool表示是否已过期，Write()开头检查，若已过期则返回 error 并跳过写入 - 关闭旧文件动作放在轮转函数末尾，但前提是：新 writer 已设好、且所有后续写入都走新路径；旧 writer 的最后一次写入已完成
- 如果用
log.SetOutput替换后立刻Close()，大概率触发 “use of closed file” panic
