Go日志染色不能直接用log.SetFlags，因其仅控制元信息开关，不支持ANSI颜色；强行注入转义序列会导致Windows旧终端乱码或破坏日志结构；可行方案为换库（如logrus/zerolog）或安全封装io.Writer。
Go 日志染色为什么不能直接用 log.SetFlags
因为 log 标准库本身不支持 ANSI 颜色序列，log.SetFlags 只能控制时间、文件名、行号等元信息的开关，完全不处理输出内容的样式。强行往 log.Printf 里塞 \033[32m 这类转义序列，在 Windows 控制台（尤其旧版 cmd）或某些 IDE 内置终端里会直接显示乱码，甚至破坏日志结构。
真正可行的路径只有两条：要么换支持染色的日志库，要么自己包装 io.Writer 做带颜色的输出目标。后者看似灵活，但容易踩坑——比如忘记判断 os.Stdout.Fd() 是否为终端（tty），导致生产环境把颜色码写进文件日志。
用 logrus + logrus.TextFormatter 快速启用染色
logrus 是最常用的替代方案，它默认不染色，必须显式启用 ForceColors 并确保 formatter 是 TextFormatter（JSONFormatter 不生效）。
- 必须设置
formatter.ForceColors = true，否则即使终端支持也会禁用颜色 - 如果程序重定向了 stdout（如
./app > app.log），要手动设formatter.DisableColors = false并配合ForceColors，否则自动降级为无色 - 级别颜色是固定的：
InfoLevel蓝、WarnLevel黄、ErrorLevel红，无法单个字段自定义（比如只给 message 染色）
import log "github.com/sirupsen/logrus"
func main() {
formatter := &log.TextFormatter{
ForceColors: true,
FullTimestamp: true,
}
log.SetFormatter(formatter)
log.Info("this line shows in blue")
}
用 zerolog 实现更轻量且可控的染色
zerolog 默认不染色，但提供 ConsoleWriter，它内部做了终端检测，比手写 os.IsTerminal 更可靠。关键点在于：它允许你通过 FormatLevel、FormatMessage 等钩子函数，对任意字段单独加色，且不影响 JSON 输出模式。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
w := zerolog.ConsoleWriter{Out: os.Stderr}会自动识别是否为终端，无需手动判断 - 想只给 level 染色？设
w.FormatLevel = func(i interface{}) string { return "\033[34m" + i.(string) + "\033[0m" } - 想在非终端环境（如管道、文件）彻底禁用颜色？传入
zerolog.ConsoleWriter{NoColor: true} - 注意：Windows PowerShell 和新版 Windows Terminal 支持 ANSI，但传统 cmd.exe 需提前调用
syscall.SetConsoleMode启用，ConsoleWriter不处理这个
自己封装 io.Writer 染色时最容易忽略的兼容性问题
很多人直接写个 struct 包裹 os.Stdout，在 Write 方法里替换字符串加颜色码。这在 Linux/macOS 下看似正常，但实际埋了三个雷：
- 没检查
os.Stdout是否为真实终端（os.Stdin.Stat().Mode() & os.ModeCharDevice == 0），导致日志文件里全是\033[31m - 没处理多字节字符（如中文），ANSI 序列插在 UTF-8 中间会破坏宽度计算，终端显示错位
- 没考虑并发：多个 goroutine 同时写同一
io.Writer，若内部用了缓存或状态机（比如等待\033[完整序列），可能产生竞态或丢日志
真要手写，建议只 wrap os.Stderr 且仅用于开发调试，生产环境务必切回无色模式或用成熟库。
颜色不是功能，是调试体验的增强；但一旦混进日志采集链路，就可能让 ELK 解析失败或 Grafana 展示异常——这点比怎么加色更重要。
