必须用gin.LoggerWithConfig()自定义Formatter函数，通过param.ClientIP、param.Latency、param.StatusCode等字段构造含IP、耗时、状态码的日志，同时调用gin.DisableConsoleColor()避免文件乱码，并配置SkipPaths过滤高频路径。
怎么让 Gin 日志带 IP、耗时、状态码，而不是默认那串时间戳加路径？
默认 gin.Logger() 输出的格式固定且信息有限，比如 [GIN] 2026/08/13 - 01:59:22 | 200 | 12.456µs | 127.0.0.1 | GET /ping，但缺少请求参数、User-Agent、响应体大小等关键字段。要自定义，必须用 gin.LoggerWithConfig() 替代默认中间件。
- 直接调用
gin.Logger()无法修改格式，它只是gin.LoggerWithConfig(gin.LoggerConfig{})的快捷封装 -
Formatter字段是核心：传入一个函数，接收gin.LogFormatterParams，返回字符串 - 注意
param.Request.PostForm.Encode()只能拿到表单数据，JSON 请求体需提前绑定或用中间件读取 body（否则为空） - 别在 Formatter 里做耗时操作（如 DB 查询），它在每次请求结束时同步执行，会拖慢响应
为什么用 gin.LoggerWithConfig 时日志全乱码或 ANSI 色彩残留？
常见现象是日志文件里出现 \x1b[32m 这类字符，grep 查不到内容，ELK 解析失败。根本原因是 Gin 默认启用控制台颜色输出，而颜色控制符对文件无效。
- 必须在创建日志文件前调用
gin.DisableConsoleColor()，否则Formatter返回的字符串仍会被套上颜色标记 - 如果同时写控制台和文件（用
io.MultiWriter(f, os.Stdout)），控制台会变黑白，但这是预期行为——文件不能有颜色，控制台牺牲色彩换一致性 - 别试图用正则在 Formatter 里过滤 ANSI 序列，Gin 内部逻辑会在写入前再套一层，治标不治本
如何把请求参数、Header、响应大小也塞进日志行？
原生 LogFormatterParams 不暴露完整请求头或响应体，但可安全访问部分字段。想加更多内容，得靠中间件预处理并存到 c.Keys。
-
param.ClientIP是可信的，但需配合TrustedProxies设置，否则可能拿到反向代理 IP -
param.StatusCode和param.Latency可直接用；param.Writer.Size()能拿到响应字节数（注意：若用了 gzip 中间件，这里仍是未压缩大小） - User-Agent 建议从
param.Request.UserAgent()取，别用param.Request.Header.Get("User-Agent")，前者做了空值保护 - 想记录 query 参数？用
param.Request.URL.RawQuery，比手动拼接param.Request.URL.Query().Encode()更可靠（保留原始编码）
生产环境 JSON 日志为啥不能只靠 Formatter 拼字符串？
手动 json.Marshal() 到字符串再返回，看似可行，但容易崩：字段名冲突、特殊字符未转义、嵌套结构难维护，且 LogFormatterParams 里没有完整上下文（如 panic 堆栈）。
立即学习“go语言免费学习笔记（深入）”；
- 真正可靠的方案是换日志库：用
logrus或zap接管输出，再把gin.LoggerWithConfig的Output指向它们的 writer - 若坚持用原生，至少把
Formatter返回值限制为 flat 字段（无嵌套），并用strings.ReplaceAll清掉换行符，否则单条日志跨多行，日志采集器会切碎 - 高频接口（如
/healthz）务必配SkipPaths: []string{"/healthz"}，否则 JSON 日志体积暴增，磁盘 IO 直接打满
最易被忽略的一点：所有自定义日志逻辑都依赖于 c.Next() 执行完毕后才触发。如果某个中间件 panic 了且没被 Recovery 捕获，这条日志就永远写不出——所以 RecoveryWithWriter 必须独立配置错误日志文件，不能指望主日志 Formatter 覆盖 panic 场景。
