gin.loggerwithwriter 是唯一可定制日志格式的入口，通过 loggerconfig.format 字符串模板控制输出，支持 {{.status}} 等字段，但不支持自定义函数、条件判断或链式方法调用；需配合 multiwriter 与缓冲写入文件和终端，并在退出前 flush；复杂需求应手写中间件。
LoggerWithWriter 是唯一可控入口
gin.Logger() 本身是硬编码格式、不可定制的封装函数，它内部直接调用 gin.LoggerWithWriter 并传入 gin.DefaultWriter 和默认配置。真正能改格式的地方只有 gin.LoggerWithWriter —— 它接受一个 io.Writer 和可选的 gin.LoggerConfig，其中 Format 字段决定日志模板。
-
Format是字符串模板，支持 {{.Status}}、{{.Latency}}、{{.ClientIP}}、{{.Method}}、{{.Path}}、{{.Time}} 等字段，不支持自定义函数或条件判断 - 不能用
gin.Logger()直接替换，必须显式调用gin.LoggerWithWriter并传入配置 - 如果同时用了
gin.Default()，它会自动挂载gin.Logger()，你得手动去掉再加LoggerWithWriter - 常见错误：只改了
gin.DefaultWriter却没换中间件，结果日志还是老格式——因为gin.Logger()根本不读DefaultWriter的格式配置
Format 字符串里的时间和延迟单位要小心
Time 默认是 RFC3339Nano 格式（如 2026/08/19 - 10:32:45.123456789），但实际输出会被截断成秒级；Latency 是 time.Duration 类型，模板里直接写 {{.Latency}} 会输出类似 1.234ms 或 567.89µs，但无法强制统一为 ms 或保留小数位数。
- 想固定毫秒且保留 3 位小数？不行，
Latency在模板里不支持.printf或方法调用 - 想用 Unix 时间戳？
{{.Time.Unix}}会 panic，模板不支持链式调用方法 - 替代方案：用
{{.Time.Format "2006-01-02 15:04:05"}}可以，这是唯一支持的格式化方式 - 如果需要更精细控制（比如纳秒级耗时、带 trace_id 的 JSON），就得绕过
LoggerWithWriter，自己写中间件
文件输出 + 格式定制必须组合使用 MultiWriter 和缓冲
只把 Format 改了，但输出目标还是 os.Stdout，那只是格式变了，没解决落盘问题；反过来，只换 DefaultWriter 到文件却不换中间件，格式还是旧的。两者必须一起动。
- 文件必须用
os.O_CREATE | os.O_WRONLY | os.O_APPEND打开，否则可能覆盖或写失败 - 裸
*os.File直接传给LoggerWithWriter会导致并发写冲突，必须套bufio.NewWriter - 用
io.MultiWriter同时写文件和终端时，两个 writer 都要各自缓冲，否则终端输出也会卡顿 - 别忘了在
main函数退出前调用bufWriter.Flush()，否则最后一段日志大概率丢失
生产环境建议跳过 LoggerWithWriter，直接手写中间件
当你要加 trace_id、用户 ID、响应体长度、或按 status code 分级别（比如 5xx 才记 error）时，LoggerWithWriter 的模板能力就捉襟见肘了。它的 Format 是静态字符串，没法做逻辑分支或字段注入。
- 手写中间件可以精确控制
c.Next()前后的行为：记录开始时间、捕获 panic、读取c.Errors、检查c.Writer.Status() - 能从
c.Request.Context()拿到 trace_id（比如来自 middleware.TraceID），也能在 defer 里安全写日志 - 避免在
Write方法里做 JSON 编码或网络调用——Gin 日志是同步阻塞的，慢操作会拖垮整个请求链路 - 如果真要用结构化日志，zap 或 logrus 集成比硬啃
LoggerWithWriter更可持续
真正难的不是拼出那行日志，而是保证它在线程安全、不丢日志、不影响请求延迟的前提下，还能带上你需要的上下文。这些细节在 LoggerWithWriter 的抽象之下全被隐藏了，一旦出问题，排查起来比重写还费劲。
