strings.TrimSpace 只移除首尾 Unicode 空白字符，不处理中间空格、不支持自定义字符集、无法识别 BOM 等特殊空白；误判“无效”常因空白不在首尾或类型不可见，应先用 %q 查看真实字符。
strings.TrimSpace 是最直接的解法，但它不处理中间空格、不识别自定义字符、也不区分 ASCII 与 Unicode 空白——用错场景反而埋坑。
为什么 strings.TrimSpace 有时像没起作用
最常见原因是：你以为的“空格”根本不在首尾。比如 "hello
" 看似结尾有换行和空格，但若字符串来自 HTTP header 或二进制解析，末尾可能混着
（Windows 换行）或 u200B（零宽空格），而 TrimSpace 其实全删了——你反而看不出变化，误判为失效。
- 肉眼无法可靠识别空白类型，尤其处理用户输入、日志行、JSON 字段值时，建议始终用
fmt.Printf("%q", s)查看真实字符 -
TrimSpace依据unicode.IsSpace判断，覆盖' '、' '、' '、' '、' '、' '、全角空格u3000、不换行空格u00A0等，但不包括某些控制字符如uFEFF（BOM） - 它只扫首尾，不遍历整个字符串，性能好；但对纯空白串（如
" "）返回空字符串""，这是预期行为
要只去左边或右边？别硬套 strings.TrimSpace
strings.TrimSpace 没有单侧版本。强行用它再截断，既啰嗦又易错。
- 只去左边空白 →
strings.TrimLeftFunc(s, unicode.IsSpace) - 只去右边空白 →
strings.TrimRightFunc(s, unicode.IsSpace) - 如果只要 ASCII 空格和制表符，用
strings.TrimLeft(s, " ")更轻量、语义更明确 -
TrimLeftFunc和TrimRightFunc每次都调用函数判断，比TrimSpace略慢，但绝大多数场景无感知
strings.Trim 不是“去空格专用”，而是按字符集裁剪
写 strings.Trim(s, " ") 只能去掉半角空格，漏掉 、
、全角空格等；而 strings.TrimSpace 才真正覆盖 Unicode 空白。
立即学习“go语言免费学习笔记（深入）”；
-
strings.Trim(s, "*#0")表示从两端持续剥离所有属于该集合的字符，不限次数、不关心顺序：例如"**##0012300##**"→"123" - 第二个参数是字符集合，不是子串；传入空字符串
""会原样返回 - 区分大小写：
strings.Trim("AbC", "ac")返回"AbC"（因为'A'和'C'不在"ac"中） - 别混淆
Trim和ReplaceAll：strings.Trim("aabbccaa", "ab")→"cc"，不是"ccaa"
需要删掉字符串里**所有**空白字符（含中间的）？strings.TrimSpace 不管这事
它只动首尾。真要全局清理，得换方法：
- 推荐
strings.Map+unicode.IsSpace：语义清晰、覆盖完整、零分配，适合生产环境 -
strings.Fields(s)+strings.Join会错误合并相邻词（如"a b"→"ab"），逻辑不等价，慎用 - 正则
regexp.ReplaceAllString(s, "\s+", "")性能开销大，小任务里纯属过度设计 - 若确定输入只有 ASCII 空格且无需兼容性，
strings.ReplaceAll(s, " ", "")最快，但不可靠
真正容易被忽略的是：空白字符的来源往往比想象中复杂——HTTP 响应头带
、JSON 解析后残留 BOM、前端传参夹带零宽字符。别依赖直觉，先 %q 看清再动手。
