应先用正则\x1b\[[0-9;]*[a-zA-Z]清除ANSI转义序列，再结合golang.org/x/term.IsTerminal或mattn/go-isatty动态判断是否需清洗，避免无条件去色。
写入文件前用正则清除 ANSI 转义序列
Go 标准库不自带 ANSI 清洗功能，终端输出的 [...m 或 u001b[...m 这类控制码会原样写入文件，导致内容不可读。最直接的办法是用正则提前剥离——匹配所有 CSI（Control Sequence Introducer）序列即可。
常见错误是只匹配 [...m，漏掉结尾可能是字母、数字或 @-~ 区间字符；更稳妥的是用 [[0-9;]*[a-zA-Z]，覆盖绝大多数颜色/样式控制码。
-
regexp.MustCompile(`[[0-9;]*[a-zA-Z]`)是最小可用正则，能处理[32m、[1;34m、[0m等 - 若日志中还混有贝尔符（
）、退格（）等，需额外清理，但颜色码场景下通常不需要 - 注意：正则编译一次复用，别在循环里反复
regexp.Compile
使用 golang.org/x/term 判断是否应过滤
不是所有输出都需要去色——比如你希望终端显示颜色、文件保留原始文本，那就该按输出目标动态决定是否清洗。Go 1.22+ 的 golang.org/x/term 提供了 IsTerminal，可配合 os.Stdout.Fd() 判断当前是否连着真终端。
典型误用是硬编码“写文件就去色”，结果导致调试时重定向到终端也去色了。正确逻辑是：只在非终端输出（如文件、管道）时才清洗。
立即学习“go语言免费学习笔记（深入）”；
-
isTerm := term.IsTerminal(int(os.Stdout.Fd()))—— 注意Fd()在 Windows 上可能 panic，生产环境建议加recover或用os.Stdin.Stat().Mode() & os.ModeCharDevice回退 - 如果输出目标是
*os.File（比如os.OpenFile返回的），直接清洗；如果是os.Stdout，先判断再决定
第三方库 mattn/go-isatty 更兼容老版本 Go
如果你还在用 Go 1.21 或更早，golang.org/x/term 可能不可用，mattn/go-isatty 是更通用的选择，API 简单且 Windows/macOS/Linux 全支持。
它不会帮你去色，只解决“要不要去”的判断问题。很多人装了却忘了调用 isatty.IsTerminal，最后还是无条件清洗，白引入依赖。
import "github.com/mattn/go-isatty"if isatty.IsTerminal(os.Stdout.Fd()) { /* 保留颜色 */ } else { /* 清洗后写入 */ }- 注意：该包对 Windows 控制台的支持依赖
CONOUT$，某些 CI 环境（如 GitHub Actions 的 windows-latest）返回 false，属正常行为
避免用 fmt.Fprintf 直接写带色字符串到文件
很多代码把 fmt.Sprintf("[31mERROR[0m") 的结果直接 io.WriteString(f, s)，这是源头污染。应该把着色逻辑和写入逻辑解耦。
真正的问题不在“怎么去掉”，而在于“为什么一开始就把控制码塞进业务数据”。更好的做法是定义结构化日志项，颜色只在最终渲染层（如 io.Writer 实现）注入。
- 例如：用
struct{ Level, Msg string }存日志，渲染器根据Level决定是否加色、加什么色 - 写文件时用纯文本渲染器，写终端时用彩色渲染器 —— 避免后期清洗，性能更好，也更易测试
- 如果已有大量
log.Printf("[...")调用，优先改调用点，而不是全局加清洗中间件
ANSI 清洗本身很简单，难的是判断“何时不该清洗”——CI 日志、systemd journal、容器 stdout/stderr 重定向等场景下，终端检测容易失效，得结合环境变量（如 NO_COLOR）或显式配置开关。别让一个正则掩盖了输出语义的混乱。
