log.setoutput 对 gin 错误日志无效，因 gin 使用独立的 gin.defaulterrorwriter（默认指向 os.stderr）处理错误；需在引擎初始化前将其设为文件或 lumberjack.logger 才能重定向。
为什么 log.SetOutput 对 Gin 的错误日志无效
Gin 默认使用自己的 gin.DefaultWriter 和 gin.DefaultErrorWriter 分别处理访问日志和错误日志（如 panic、中间件异常、路由未匹配等）。直接调用标准库的 log.SetOutput 只会影响你手动调用 log.Print* 的输出，对 Gin 内部触发的错误日志完全没作用。
真正起效的是替换 Gin 的错误写入器 —— 即 gin.DefaultErrorWriter 这个全局变量（类型为 io.Writer）。
- 它默认指向
os.Stderr，所以错误都打到终端 - 只要在
gin.Default()或gin.New()之前把它设成一个文件句柄，就能重定向全部 Gin 错误日志 - 注意：必须在任何路由注册或引擎启动前设置，否则部分早期错误（如初始化 panic）仍会走默认 stderr
如何用 os.OpenFile 安全打开日志文件
不能简单用 os.Create，否则每次启动都会清空旧日志；也不能只用 os.OpenFile 不加 flag，容易因权限或路径问题失败。
推荐写法：
file, err := os.OpenFile("gin-error.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
if err != nil {
log.Fatalf("无法打开错误日志文件: %v", err)
}
defer file.Close() // 注意：这里不能 defer，因为要长期持有 writer
gin.DefaultErrorWriter = file
-
os.O_APPEND确保新日志追加而非覆盖 -
os.O_CREATE自动创建不存在的目录？不，它只建文件；目录需提前存在或自行os.MkdirAll - 权限
0644是常规选择，避免因无写权限导致静默失败 -
defer file.Close()在这里反而是错的 —— Gin 会持续写入，关闭后后续写操作会 panic
生产环境必须考虑的日志轮转与并发安全
Gin 的 DefaultErrorWriter 是全局变量，所有 goroutine 共享。如果直接塞入普通 *os.File，本身是线程安全的（内核级 write 是原子的），但缺乏日志切割能力，单文件会无限增长。
- 简单项目可用
lumberjack.Logger（第三方包）替代*os.File，它自带按大小/时间轮转、压缩、保留份数功能 - 示例：
gin.DefaultErrorWriter = &lumberjack.Logger{Filename: "gin-error.log", MaxSize: 10, MaxBackups: 5, MaxAge: 28} - 不要自己用
time.Ticker定时 reopen 文件 —— 并发写入时极易出现丢失或 panic - 若用 systemd 部署，也可交由
StandardError=journal+journalctl管理，此时反而不该重定向到文件
验证是否生效的最快方式
别等真出 panic —— 主动触发一个可复现的错误最可靠。
- 加一条路由：
r.GET("/panic-test", func(c *gin.Context) { panic("test panic from handler") }) - 访问该 URL，检查目标文件是否有类似
[GIN] 2024/05/20 - 10:30:45 | 500 | ... | 1.2345ms | 127.0.0.1 | GET "/panic-test"和 panic 堆栈 - 如果文件没内容，但终端有输出 → 说明
DefaultErrorWriter没设对或设晚了 - 如果文件有内容但堆栈不全（比如缺 goroutine 信息）→ 检查是否被其他中间件捕获并吞掉了 panic（例如用了
recovery但没配置LogFunc）
最关键的细节：Gin 的错误日志包含两部分——框架自身的 HTTP 错误行（如 404、500 状态行），以及 panic 时的完整堆栈。后者只有在未被 recovery 中间件拦截时才会落到 DefaultErrorWriter。如果用了自定义 recovery，记得把错误也写进你的日志文件里，而不是只依赖全局 writer。
