Go标准库log包不支持着色因其Output方法硬编码格式化逻辑且无扩展钩子；安全方案是用可配置的io.Writer（如ColoredWriter）封装着色，仅对终端生效，并推荐结构化日志器（如zerolog）实现字段级定制。
为什么默认的 log 包不支持着色，且无法安全扩展
Go 标准库的 log 包是线程安全但高度封闭的：它的输出逻辑硬编码在 Output 方法里，SetOutput 只能换写入目标（如 os.Stderr），无法拦截或修改日志内容本身；所有格式化（时间、前缀、换行）都在内部完成，没有钩子。你不能在不重写整个 Logger 实例的前提下插入 ANSI 颜色码或结构化字段。
直接在消息字符串里拼接 \x1b[32m 等控制码看似可行，但会污染日志内容——当输出到文件或 JSON 后端时，这些颜色码变成垃圾字符；更糟的是，如果日志被管道传给 grep 或 jq，控制码可能破坏解析。
- 必须把着色逻辑与输出目标解耦：终端才着色，文件/网络不着色
- 格式化行为（如字段顺序、时间格式、是否加括号）需可配置，而非写死
- 避免全局状态污染：
log.SetFlags是包级全局变量，多模块共用时易冲突
用 io.Writer 封装着色逻辑，而不是改造 log.Logger
核心思路是：不碰 log.Logger 本身，而是实现一个带条件着色能力的 io.Writer，再把它传给 log.New。这样既复用标准库的线程安全和缓冲机制，又把着色、格式化等定制逻辑收口到 Writer 层。
关键点在于判断当前输出是否连到终端（TTY）。Linux/macOS 用 os.Stdout.Fd() + syscall.IoctlGetTermios，Windows 用 kernel32.GetStdHandle + GetConsoleMode；但更简单可靠的是用现成库如 golang.org/x/term 的 IsTerminal 函数。
立即学习“go语言免费学习笔记（深入）”；
type ColoredWriter struct {
w io.Writer
enableColor bool
}
func (cw *ColoredWriter) Write(p []byte) (n int, err error) {
if cw.enableColor && term.IsTerminal(int(os.Stdout.Fd())) {
p = append([]byte("\x1b[36m"), append(p, []byte("\x1b[0m")...)...)
}
return cw.w.Write(p)
}
logger := log.New(&ColoredWriter{w: os.Stderr, enableColor: true}, "", log.LstdFlags)
-
Write方法里做着色，不是在Printf之前拼字符串 -
enableColor必须可配，否则无法禁用（比如 CI 环境） - 不要在
Write里做复杂格式化（如解析时间戳）——那是日志器的事；Writer 只负责“渲染”已格式化的字节流
用结构化日志器替代 log.Printf 才能真正支持字段级定制
如果你需要按 level 给不同字段着色（如 level=ERROR 用红字、msg 用白字、file=xxx.go 用蓝字），或者想把 time="2024-05-20T14:23:11Z" 改成 [2024-05-20 14:23]，log 包的扁平字符串模型根本做不到。这时候必须切换到结构化日志器，如 zerolog 或 zap。
zerolog 轻量且 API 直接：它把日志看作 map[string]interface{}，通过 ConsoleWriter 提供字段级着色控制：
w := zerolog.ConsoleWriter{Out: os.Stderr}
w.FormatLevel = func(i interface{}) string {
switch i {
case "error": return "\x1b[31mERROR\x1b[0m"
case "info": return "\x1b[32mINFO\x1b[0m"
default: return strings.ToUpper(fmt.Sprint(i))
}
}
w.FormatFieldName = func(i string) string {
return "\x1b[34m" + i + "\x1b[0m:"
}
log := zerolog.New(w).With().Timestamp().Logger()
-
FormatLevel/FormatFieldName/FormatFieldValue这三个钩子覆盖了绝大多数定制需求 - 注意
ConsoleWriter默认只对终端生效（内部调用term.IsTerminal），导出到文件时自动跳过着色 - 别在
FormatXXX函数里做耗时操作（如 HTTP 请求、磁盘读取），它们在每条日志路径上同步执行
避免在生产环境误开着色导致日志解析失败
最常被忽略的一点：着色开关不能只靠环境变量（如 LOG_COLOR=1）或编译标签控制，而要结合实际输出目标动态判断。CI/CD 流水线中，即使设置了 LOG_COLOR=1，日志也可能被重定向到文件或转发到 ELK，此时颜色码就是噪音。
- 优先用
term.IsTerminal(fd)判断，而非单纯读环境变量 - 如果必须强制着色（如调试容器内进程），提供显式开关（如
--color=always），并文档注明风险 - 在日志系统入口处统一处理：比如封装一个
NewLogger(opts ...LoggerOption)，内部根据os.Stdout是否为终端、是否启用 debug 模式、是否在 Kubernetes Pod 中运行等组合决策
颜色只是表层，真正难的是让着色、时间格式、字段顺序、序列化目标（console/json/file）这四者解耦又协同——它们不该是 if-else 堆出来的，而应由独立可插拔的组件各自负责。
