strings.trimspace 移除所有 unicode.isspace 认定的空白符，包括 ' '、'\t'、'\n'、'\r'、'\f'、'\v'、全角空格 '\u3000'、零宽空格 '\u200b'、行分隔符 '\u2028' 等，但不处理 '\u00a0' 和 bom '\ufeff'。
strings.TrimSpace 是什么，它到底删哪些字符
strings.TrimSpace 不是“去掉空格”，而是移除所有满足 unicode.IsSpace 的 Unicode 空白符。它覆盖：' '、'\t'、'\n'、'\r'、'\f'、'\v'、全角空格 '\u3000'、零宽空格 '\u200B'、行分隔符 '\u2028' 等。但不处理不间断空格 '\u00A0'（有些版本支持，取决于 Go 版本和 unicode 包实现），也不处理 BOM '\uFEFF'。
常见误判是看到字符串没变——其实是因为你以为的“空格”在中间，或者根本不是 unicode.IsSpace 认定的空白（比如 '\u00A0'）。调试时务必用 fmt.Printf("%q", s) 看真实码点。
为什么别用正则做首尾清理
写 regexp.MustCompile(`^\s+|\s+$`).ReplaceAllString("", s) 看似灵活，实际是性能陷阱：
- 编译正则有开销，哪怕复用
*regexp.Regexp，匹配过程仍需构建状态机、回溯判断 -
\s在不同正则引擎中语义不一；Go 的regexp默认不包含\u3000等 Unicode 空格，得显式写[[:space:]\u3000\u2000-\u200F\u2028\u2029] - 每次调用都新建字符串、遍历两次（一次找边界，一次替换），而
strings.TrimSpace是单次双指针扫描 + 切片，O(n) 但常数极小 - 对空字符串或纯空白串，
TrimSpace直接返回""，无额外分配；正则至少触发一次匹配逻辑
什么时候才该考虑正则或自定义方案
仅当需求超出 TrimSpace 能力边界时才引入复杂度：
- 要同时删首尾空白 + 中间多余空格（如 HTML 内联文本清洗）→ 用
regexp.ReplaceAllString或strings.FieldsFunc+strings.Join - 需保留某些空白（如只删
' '和'\t'，但留'\n'）→ 改用strings.Trim(s, " \t") - 要跳过 BOM 或按上下文条件删（如开头是
'#'且后跟空格才删）→ 用strings.TrimLeftFunc组合判断 - 输入确定含
'\u00A0'且必须兼容 → 手动扩展：strings.Trim(s, " \t\n\r\f\v\u00A0\u3000")，比正则轻量且可控
最容易被忽略的赋值问题
strings.TrimSpace 返回新字符串，原变量不变。这看似常识，但在批量处理或嵌套调用时高频出错：
- 错误：
strings.TrimSpace(s)（返回值丢弃） - 正确：
s = strings.TrimSpace(s) - 切片批量处理必须显式索引赋值：
for i := range ss { ss[i] = strings.TrimSpace(ss[i]) } - 链式调用如
strings.TrimSpace(strings.TrimPrefix(s, "key:"))没问题，但每层都生成新字符串，若原串极大且频繁调用，内存压力会暴露
真正麻烦的不是函数选错，而是以为“调用了就生效”，结果数据里还躺着 '\uFEFF' 或 '\u200B' —— 它们肉眼不可见，却让 == 比较失败、JSON 解析报错、数据库唯一约束冲突。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
