Go程序在Windows旧版CMD中ANSI颜色不生效，因默认禁用转义序列解析；推荐用github.com/mattn/go-colorable自动启用虚拟终端并适配重定向场景。

Go 本身不内置终端颜色支持，必须靠 ANSI 转义序列或第三方库；直接写 \x1b[32m 能用，但跨平台和可维护性差，推荐用 github.com/mattn/go-colorable + github.com/mattn/go-isatty 组合。

为什么 fmt.Printf("\x1b[31merror\x1b[0m") 在 Windows CMD 下不生效

Windows 旧版终端（如 CMD、PowerShell 5.1 及更早）默认禁用 ANSI 转义序列解析。即使 Go 程序输出了 \x1b[31m，系统也当普通字符显示。

• Go 1.12+ 在 os.Stdout / os.Stderr 上自动检测并启用 ANSI（仅限 Windows 10 1607+ 且开启 Virtual Terminal Level）
• 但若重定向到文件、管道，或运行在老旧 Windows 环境，os.Stdout 会退化为不可着色的 *os.File
• 直接硬编码转义序列无法判断当前输出是否真能被渲染，容易“静默失败”

用 colorable.NewColorable(os.Stdout) 安全包裹输出流

这是最轻量、无依赖升级风险的方案：它在 Windows 下自动调用 SetConsoleMode 启用虚拟终端，在 Linux/macOS 下透传原生流，还能识别重定向场景并降级。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

• 始终用 colorable.NewColorable(os.Stdout) 替代裸 os.Stdout，尤其在 log.SetOutput() 或自定义 writer 场景
• 对 os.Stderr 同理，用 colorable.NewColorable(os.Stderr)
• 无需手动检测 isatty.IsTerminal() —— go-colorable 内部已处理
• 示例：

  import (
      "fmt"
      "os"
      "github.com/mattn/go-colorable"
  )
  w := colorable.NewColorable(os.Stdout)
  fmt.Fprint(w, "\x1b[32mOK\x1b[0m\n")

避免用 golang.org/x/term 做颜色控制

golang.org/x/term 是为读取用户输入（如密码掩码、行编辑）设计的，不提供颜色输出能力。有人误以为 term.IsTerminal() 能替代着色逻辑，但它只返回布尔值，不修改输出行为。

立即学习“go语言免费学习笔记（深入）”；

• term.IsTerminal() 适合做“是否启用进度条”的开关，但不能让颜色变生效
• 想封装颜色函数？直接用 \x1b[1;33m（黄粗体）等标准序列即可，无需额外抽象层
• 如果项目已用 spf13/cobra，注意其 cmd.SetOut() 接收的是 io.Writer，仍需先 wrap 成 colorable 实例

真正麻烦的不是怎么写绿色字，而是输出流在 CI 日志、重定向文件、老旧 Windows 上自动闭嘴还不报错。把 colorable.NewColorable 当成和 os.Stdout 一样基础的初始化步骤，比事后调试颜色消失省半小时。