strings.trimspace 过滤 unicode 定义的所有空白符，包括 '\t'、'\n'、'\r'、'\f'、'\v'、u+0085、u+00a0、u+1680、u+2000–u+200a、u+2028、u+2029、u+202f、u+205f、u+3000 等 zs/zl/zp 类字符，但不处理零宽空格（u+200b）、bom（u+feff）等非空白控制符。
strings.TrimSpace 会过滤哪些字符？
strings.TrimSpace 不是只删空格，它过滤的是 Unicode 定义的「空白符（White Space）」，包括 '\t'、'\n'、'\r'、'\f'、'\v' 和所有 Unicode 类别 Zs（如不换行空格 '\u00A0'）、Zl（行分隔符）、Zp（段落分隔符）中的字符。
这意味着它会删掉中文全角空格 '\u3000'，但不会删零宽空格 '\u200B'（属于 Cf 类别，非空白符），也不会删软连字符 '\u00AD'。
- 常见误判：以为只处理 ASCII 空格和制表符，实际覆盖范围广得多
- 验证方式：用
unicode.IsSpace(rune)判断单个字符是否被TrimSpace清除 - 注意：某些看似“空白”的符号（如
'\uFEFF'BOM 字符）不属于空白符，TrimSpace不处理
为什么 TrimSpace 对中文文本有时“没效果”？
因为中文排版中常用的是全角空格 '\u3000'、不间断空格 '\u00A0' 或零宽空格 '\u200B'，而 TrimSpace 虽然能处理前两者（'\u3000' 属于 Zs，'\u00A0' 是标准不换行空格），但对 '\u200B'、'\u2060'（Word Joiner）等隐形控制符完全无感。
- 典型现象：肉眼看着开头有“空”，
TrimSpace后长度没变 - 排查建议：用
fmt.Printf("%q", []byte(s))或逐字符打印fmt.Printf("%U ", r)查看真实码点 - 若需清理更广义“视觉空白”，得手动补充：
strings.ReplaceAll(s, "\u200B", "")或用正则匹配\p{C}类控制字符（需谨慎）
TrimSpace 和 Trim、TrimRight 有什么关键区别？
strings.TrimSpace 是 strings.Trim 的特化封装，等价于 strings.Trim(s, " \t\n\r\f\v\u0085\u00a0\u1680\u2000-\u200a\u2028\u2029\u202f\u205f\u3000")（Go 源码里硬编码的空白字符集），但它只作用于首尾；而 Trim 允许传入任意字符集，TrimRight 只处理右侧。
-
TrimSpace性能略优：内部做了优化，比Trim(s, " \t\n...")少一次字符串构建 - 不要用
Trim传动态生成的空白字符列表——易漏、难维护，且无法覆盖 Unicode Zs 类 - 若只需去首或尾，用
TrimLeft/TrimRight更语义清晰，但它们也不识别 Unicode 空白类别，得手动列全
生产环境里容易忽略的边界情况
最常踩的坑不是功能不对，而是没意识到 TrimSpace 对空字符串、全空白字符串、含 BOM 的字符串的行为差异。
- 输入
""→ 输出""（没问题） - 输入全是空白（如
"\t\n\u3000"）→ 输出""（符合预期） - 输入带 UTF-8 BOM（
"\xEF\xBB\xBF hello"）→TrimSpace不动 BOM，结果仍是"\xEF\xBB\xBF hello"，后续解析可能失败 - 如果字符串来自 HTTP body 或文件读取，建议先用
bytes.TrimPrefix(data, []byte("\xEF\xBB\xBF"))剥离 BOM，再转 string 调TrimSpace
Unicode 空白定义本身在不同 Go 版本间基本稳定，但如果你依赖特定字符（比如某个冷门 Zs 字符），最好显式测试其行为，而不是假设“反正 TrimSpace 都管”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
