应使用 github.com/fatih/color 库而非手动拼接 ansi 转义序列，因其自动处理 windows 终端兼容、输出重定向降级、并发安全及环境感知降色等问题。
直接用 github.com/fatih/color，别自己拼 \x1b[31m，否则 windows、ci、重定向全会出问题。
为什么不能直接 fmt.Printf("\x1b[32mok\x1b[0m")
手动写 ANSI 转义序列看似轻量，但实际踩坑密集：
- Windows 旧版 cmd 默认禁用虚拟终端，
\x1b[32m会原样打印成乱码，不是颜色失效，是系统根本不处理 - 输出重定向到文件（
./cli > log.txt）时，ANSI 字符照常写入，日志里全是^[[31merror^[[0m这种不可读内容 -
fmt.Printf格式串里混 ANSI 容易触发 panic，比如fmt.Printf("\x1b[%sm%s", "1;33", "warn")中的%s会被误解析 - 漏写
\x1b[0m会导致后续所有输出持续染色，跨 goroutine 或 panic 后极难定位
color.New() 和 color.Blue() 的区别在哪
两者都来自 github.com/fatih/color，但行为差异关键在「是否自动重置」和「是否可复用」：
-
color.Blue("msg")是一次性调用，内部自动加\x1b[0m，适合简单日志，但无法组合样式（比如不能同时加粗+红+背景） -
color.New(color.FgRed, color.Bold)返回一个可复用实例，支持链式叠加、多次调用，且每次输出都自带重置，适合 CLI 中反复使用的状态提示 - 别把
color.New()实例全局声明后并发调用——它不是线程安全的；应按需创建，或用color.New().Sprint(...)这类无副作用方法
如何让颜色在 CI、Docker、Windows 全部正常
核心是别硬编码开关，靠环境感知自动降级：
- 默认不用动
color.NoColor—— 它本身已检查NO_COLOR、TERM=dumb、isatty，足够可靠 - Docker Alpine 容器中
os.Getenv("TERM")常为空，但实际支持颜色，此时得补一层isatty.IsTerminal(os.Stdout.Fd())判断 - Windows 下无需手动调
SetConsoleMode：fatih/color内部已用github.com/mattn/go-colorable自动启用虚拟终端 - 若必须强制禁用（如某条命令专用于生成机器可读输出），用
color.New(color.WithoutColor).Println(...)，比改全局NoColor更安全
和 log.Logger 混用时怎么避免颜色污染
color.Output 是个带状态的 io.Writer，直接塞给 log.SetOutput 会导致时间戳、前缀全被染色，而且可能因缓冲引发乱序：
- 正确做法是封装函数，只对消息体着色：例如
func LogError(v interface{}) { color.New(color.FgRed, color.Bold).Fprintf(os.Stderr, "ERROR: %v\n", v) } - 务必指定
os.Stderr，不要传log.Writer()—— 后者返回的是带前缀的包装器，颜色控制符会插在时间戳中间 - 如果要用
log输出结构化日志（如 JSON），绝对不要加颜色；颜色只用于人眼阅读的 CLI 主流程输出
真正容易被忽略的点是：颜色逻辑不该侵入业务代码路径。把 color.New(...) 实例作为参数传入，或通过接口抽象（如 Printer 接口），才能在测试时轻松替换为无色实现，而不是靠条件编译或环境变量临时开关。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
