Gin 的 gin.DefaultWriter 不能直接写多个文件，因其本质是 io.MultiWriter，仅支持复制写而非条件路由写，无法按状态码等动态分发日志到不同文件。
为什么 Gin 的 gin.DefaultWriter 不能直接写多个文件
Gin 默认用 gin.DefaultWriter（本质是 io.MultiWriter）把日志输出到 os.Stdout 和 os.Stderr，但它只接收一个写入目标集合，不支持按请求路径、状态码或时间动态路由到不同文件。硬塞多个 *os.File 进去会导致所有日志混写到所有文件，没法分离。
真正要“输出到多个文件”，得自己接管日志写入逻辑，而不是在默认 writer 上叠层。
- 别试图用
gin.SetMode(gin.ReleaseMode)后再改gin.DefaultWriter—— 它不处理文件轮转或分类 - 不要在中间件里每次请求都
os.OpenFile(..., os.O_APPEND|os.O_CREATE)—— 文件句柄泄漏风险高 - 必须用带缓冲和并发安全的写入器，比如
lumberjack.Logger或自行封装sync.Pool+bufio.Writer
如何用 lumberjack.Logger 实现按 HTTP 状态码分文件
最常见需求是把 2xx、4xx、5xx 日志分别写入 access-2xx.log、access-4xx.log、access-5xx.log。关键不是“多个文件”，而是“同一请求只写一个文件”，且写入器需支持自动切割和压缩。
先定义三个 lumberjack.Logger 实例，每个绑定不同文件名和切割策略：
立即学习“go语言免费学习笔记（深入）”；
var (
log2xx = &lumberjack.Logger{
Filename: "logs/access-2xx.log",
MaxSize: 100, // MB
MaxBackups: 7,
MaxAge: 28, // days
Compress: true,
}
log4xx = &lumberjack.Logger{...} // 同上，仅 Filename 不同
log5xx = &lumberjack.Logger{...}
)然后在中间件中根据 c.Writer.Status() 选择写入器：
func MultiFileLogger() gin.HandlerFunc {
return func(c *gin.Context) {
start := time.Now()
c.Next() // 执行后续 handler
<pre class='brush:php;toolbar:false;'> status := c.Writer.Status()
var logger io.Writer
switch {
case status >= 200 && status < 300:
logger = log2xx
case status >= 400 && status < 500:
logger = log4xx
case status >= 500:
logger = log5xx
default:
logger = log2xx
}
entry := fmt.Sprintf("[%s] %s %s %d %s %s\n",
time.Now().Format("2006/01/02 15:04:05"),
c.Request.Method,
c.Request.URL.Path,
status,
c.Keys["cost"].(time.Duration).String(),
c.ClientIP(),
)
logger.Write([]byte(entry))
}}
- 务必在
c.Next()之后读c.Writer.Status()，否则总是 0 -
lumberjack.Logger是线程安全的，但别在中间件里反复 new 它 —— 全局复用实例 - 如果用
log.New(logger, "", 0)包一层，注意去掉log.LstdFlags，否则时间戳会重复
如何避免日志丢失或阻塞主线程
直接调 logger.Write() 是同步阻塞的，尤其当磁盘慢或文件满时，可能拖慢整个请求。生产环境必须异步化。
最轻量做法：用带缓冲的 channel + 单 goroutine 消费：
type LogEntry struct {
Writer io.Writer
Msg string
}
var logCh = make(chan LogEntry, 1000)
<p>func init() {
go func() {
for entry := range logCh {
entry.Writer.Write([]byte(entry.Msg))
}
}()
}</p><p>// 中间件里改为：
logCh <- LogEntry{Writer: logger, Msg: entry}</p>- channel 缓冲大小设为 1000 是经验值，压测时观察是否频繁丢日志（
select { case logCh <- ...: ... default: ... }可降级为丢弃） - 别用
log.SetOutput绑定到 channel —— Gin 不走标准库log，它只认gin.LoggerWithWriter - 如果已有 Prometheus metrics 或 Sentry，建议只把 error 级日志（5xx / panic）同步写，其余异步
为什么不用 gin.LoggerWithWriter 配合 io.MultiWriter
有人试过：gin.LoggerWithWriter(io.MultiWriter(f1, f2, f3))，结果发现所有请求日志同时出现在三个文件里 —— 因为 io.MultiWriter 是“复制写”，不是“路由写”。它没法根据内容做条件分发。
除非你写个自定义 io.Writer 实现，在 Write(p []byte) 里解析日志行、提取状态码、再转发到对应文件，但这违背了中间件职责，也增加解析开销和格式耦合（比如 Gin 默认日志格式变动就崩）。
-
gin.LoggerWithWriter适合统一输出到 syslog 或网络 endpoint，不适合文件分类 - 想保留 Gin 原生日志格式（含延迟、method、path），就得在中间件里手动拼字符串，而不是依赖它的内置格式器
- 如果真要用
gin.LoggerWithWriter，只能配合外部日志收集器（如 filebeat）做 post-processing 分类，延迟高、运维成本大
文件路径权限、目录不存在、磁盘满这些基础问题，得在服务启动时主动 os.MkdirAll("logs", 0755) 并检查 os.Stat，别等第一条日志写入才暴露。
