Go标准库不支持ANSI颜色但可手动拼接转义序列；Windows旧版控制台默认禁用ANSI，需启用虚拟终端模式或使用go-colorable适配；应通过环境变量而非Stat判断终端，并用常量封装颜色避免出错。
Go 本身标准库不支持 ANSI 颜色控制，但用 fmt 拼接 ANSI 转义序列是完全可行的——只要终端支持，且你避开 Windows 默认控制台（旧版 cmd.exe）的坑。
为什么 fmt.Printf("\x1b[31mhello\x1b[0m") 有时没颜色？
根本原因是：Windows 旧版控制台默认禁用 ANSI 转义序列解析；Go 程序在该环境下直接输出 \x1b[31m 会被当成乱码或忽略。
- Windows 10 1511+ 启用虚拟终端模式后可支持（需调用
SetConsoleMode或使用github.com/mattn/go-colorable自动适配） - PowerShell、WSL、Git Bash、VS Code 终端、iTerm2 等现代终端基本都原生支持
- 别依赖
os.Stdout.Stat().Mode() & os.ModeCharDevice != 0判断是否为终端——它在 Docker 容器或重定向时不可靠 - 更稳妥的做法是检查环境变量：
os.Getenv("NO_COLOR") != ""或os.Getenv("TERM") == "dumb"
用 const 定义颜色比硬编码 \x1b 序列更安全
手写 \x1b[32m 容易拼错、漏 \x1b[0m 重置，且难以维护。定义常量 + 封装函数能显著降低出错率。
const (
Red = "\x1b[31m"
Green = "\x1b[32m"
Yellow = "\x1b[33m"
Blue = "\x1b[34m"
Reset = "\x1b[0m"
)
func RedString(s string) string { return Red + s + Reset }
fmt.Println(RedString("error:"), "file not found")
- 所有颜色常量必须以
\x1b[...m格式结尾，且务必配对Reset，否则后续输出持续染色 - 避免在日志中无条件加颜色——CI 环境（如 GitHub Actions）通常不渲染颜色，还可能污染结构化日志
- 如果项目需要多级样式（加粗、下划线），用
\x1b[1m、\x1b[4m等，但注意部分终端不支持下划线
第三方库不是必须的，但 colorable 可解决 Windows 兼容性痛点
如果你不想自己处理 Windows 控制台初始化，github.com/mattn/go-colorable 是最小侵入的方案：它包装 os.Stdout，自动检测并启用虚拟终端模式。
import "github.com/mattn/go-colorable"
func main() {
w := colorable.NewColorableStdout()
fmt.Fprintln(w, "\x1b[36mHello, cyan!\x1b[0m")
}
- 它只影响 Windows；Linux/macOS 下直接透传，无额外开销
- 不要对
colorable.Writer做类型断言或反射操作——它不是*os.File - 若已用
log.SetOutput()，记得把colorable.NewColorableStdout()传进去，而非原始os.Stdout - 别用
golang.org/x/term来“判断是否支持颜色”——它只管尺寸和输入，不管颜色渲染能力
真正容易被忽略的点是：颜色不是功能需求，而是用户体验增强项。上线前务必在目标部署环境（尤其是 Windows Server 的 CMD、Docker 的 alpine 镜像）里实测输出是否正常，而不是只在本地开发机上看着漂亮就认为没问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
