Windows控制台默认禁用虚拟终端支持，导致ANSI序列原样输出或乱码；应使用github.com/mattn/go-colorable自动启用，而非手动调用SetConsoleMode，因其跨平台兼容、重定向自动降级且无额外开销。
为什么直接用 fmt.Printf("\x1b[31m%s\x1b[0m", "text") 在 Windows 上常失效
不是代码写错，是 Windows 控制台默认关闭了虚拟终端支持。Win10 1607+ 系统虽已内置 ANSI 支持，但 Go 进程启动时仍需显式启用 ENABLE_VIRTUAL_TERMINAL_PROCESSING 标志，否则 \x1b[31m 这类序列会被原样输出或显示为乱码。
常见错误现象：cmd.exe 里看到 ←[31mERROR←[0m，PowerShell 或 WSL 正常——说明问题出在 Windows 控制台模式，而非 Go 本身。
- 别手动调
golang.org/x/sys/windows.SetConsoleMode：底层 syscall 易出错，且只适用于 Windows - 更稳妥的做法是用
github.com/mattn/go-colorable，它在NewColorableStdout()内部自动检测并启用该标志 - Linux/macOS 下它直接透传，无额外开销；重定向到文件时自动降级为纯文本，不污染日志
用 fatih/color 时 color.NoColor = true 别硬编码
这个赋值会全局禁用所有颜色，且无法被环境变量覆盖。CI 环境（如 GitHub Actions）通常靠 NO_COLOR=1 或 TERM=dumb 控制，硬编码 color.NoColor = true 会导致本地开发也变黑白，还查不出原因。
正确做法是让库自己判断：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
fatih/color默认检查NO_COLOR、TERM=dumb、是否为 TTY，足够可靠 - 若需额外判断（如
CI=true），应在main()开头加：if os.Getenv("CI") != "" { color.NoColor = true } - 避免在日志封装层或工具函数里无条件设
NoColor，尤其不要放在init()中
重定向或管道场景下颜色没消失？检查 io.Writer 链路是否被污染
把 color.Output 直接传给 log.SetOutput() 没问题，但若又把它塞进 sql.DB.SetLogger() 或其他非标准日志接口，可能因缓冲、并发写或 writer 复用导致颜色乱序、panic，甚至 ANSI 序列泄露到文件。
根本原因是 color.Output 是带状态的包装器，不是纯写入器。
- 确认第三方库文档是否明确支持
io.Writer类型的彩色输出（如logrus支持，但很多 ORM 不支持） - 对非预期接口，改用
color.New().SprintXXX()先生成字符串，再传给目标接口 - 测试重定向场景：
go run main.go > out.txt && cat out.txt，确保文件内容不含\x1b[
golang.org/x/term.IsTerminal(os.Stdout.Fd()) 只能判断，不能渲染
这个函数常被误认为“用了它就能安全输出颜色”，但它只返回 true 或 false，不处理任何 ANSI 序列，也不帮你开启 Windows 虚拟终端。它只是决策依据之一。
真正需要组合判断的顺序是：
- 先查
os.Getenv("NO_COLOR") != ""（优先级最高） - 再查
os.Getenv("TERM") == "dumb"或os.Getenv("CI") != "" - 最后用
term.IsTerminal(int(os.Stdout.Fd()))确认是否连真实终端 - 三者任一为真，就该跳过颜色输出——哪怕你用了
go-colorable，它内部也是按这套逻辑走的
手动拼 \x1b[32m 时漏掉 \x1b[0m 重置，或在 panic 前未 flush，都可能导致后续所有输出带色，这种 bug 往往跨 goroutine，排查成本远高于引入一个轻量库。
