strings.trimspace 清不掉 ansi 颜色码，因其仅移除空白字符（ 和空格），而 ansi 转义序列（如[32m）是普通字节；需用正则 regexp.mustcompile([[0-9;]*[a-za-z]|][^]*\|[a-za-z]).replaceallstring(s, "") 清洗。
为什么 strings.TrimSpace 清不掉 ANSI 颜色码
因为 ANSI Escape 序列（如 [32m、[0m）本质是普通字节，不是空白字符，strings.TrimSpace 只删
和空格，对它们完全无效。你看到的“多余颜色残留”或“长度计算错误”，根源就是这些控制码还躺在字符串里没被识别和剥离。
用正则匹配并替换 ANSI 转义序列最直接
Go 标准库没有内置 ANSI 清洗函数，但用 regexp 一行就能搞定。关键是要覆盖常见格式：[...（CSI）、]...（OSC）、[...（可能嵌套）等。推荐这个经过验证的正则：
var ansiRegex = regexp.MustCompile(`[[0-9;]*[a-zA-Z]|][^]*\|[a-zA-Z]`)
使用时直接调用 ansiRegex.ReplaceAllString(input, "") 即可。注意两点：
-
ReplaceAllString比ReplaceAll更安全，避免字节 vs rune 边界问题 - 不要用
ReplaceAllLiteralString—— 它不支持正则，会把整个模式当字面量处理 - 若需保留部分样式（比如只去颜色、不去光标移动），得拆成多个正则分别处理
清洗后长度 ≠ 显示宽度，别拿 len() 当可视长度
ANSI 码本身不占显示空间，但清洗后字符串的 len() 是字节数，而中文、emoji 等 Unicode 字符在 UTF-8 下占多字节，len() 会高估实际宽度。真正要算终端显示宽度，得用 golang.org/x/text/width：
import "golang.org/x/text/width" w := width.StringWidth(ansiRegex.ReplaceAllString(s, ""))
常见陷阱：
-
utf8.RuneCountInString()给的是 rune 数，不是显示宽度（一个 emoji 可能占 2 个终端列） - 某些宽字符（如全角 ASCII）会被
width包识别为双宽，但默认不启用 —— 要显式调用width.Narrow或width.EastAsianAmbiguous - 如果清洗后还要做截断（比如日志行限宽），务必先清洗、再测宽、最后截断，顺序错一步就出乱码
第三方库 mattn/go-isatty 和 charmbracelet/bubbletea 的清洗逻辑差异
很多终端库自带清洗函数，但行为不一致：mattn/go-isatty 的 IsTerminal 不清洗，只判断；而 bubbletea 的 text.Width() 内部已集成 ANSI 剥离 —— 它用的是自定义 parser，比正则更健壮（能处理中断的 ESC 序列），但不开源核心逻辑。实际选型建议：
- 纯清洗需求：用上面的正则，轻量、可控、无依赖
- 已引入
bubbletea且需宽度计算：直接用text.Width(s)，它自动清洗 + 测宽 - 需要处理不完整转义序列（比如日志流被截断）：正则会漏掉末尾不完整的
[31，此时得手写状态机，不能依赖简单匹配
真正难的从来不是去掉颜色，而是确认哪些序列该留、哪些该删、删完怎么算宽——尤其当输入来自不同终端模拟器或 SSH 客户端时，ESC 序列的完整性根本没法保证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
