strings.TrimSpace 去除首尾所有 Unicode 空白字符（如\t、\n、\u3000、\u200B等），非仅 ASCII 空格；只影响首尾，中间保留；返回新字符串；调试建议用 %q 查看真实字符。
Go 的 strings.TrimSpace 真的只去首尾空格吗？
strings.TrimSpace 去的不是“空格”，而是所有 Unicode 定义的空白字符（包括 \t、\n、\r、\f、\v，以及全角空格、零宽空格等）。它会从字符串开头和结尾持续切掉任何满足 unicode.IsSpace() 的字符，直到遇到第一个非空白字符为止。
常见误判是看到字符串里有空格但没被去掉——那大概率是中间的空格，或者你以为是空格其实是 \u00A0（不换行空格）或 \u200B（零宽空格），这些 TrimSpace 能处理；但如果是中文全角空格 （U+3000），它也能处理，因为 unicode.IsSpace('\u3000') 返回 true。
- 只影响首尾，中间空白原样保留
- 不修改原字符串，返回新字符串（Go 字符串不可变）
- 对空字符串、全空白字符串都安全，返回空字符串
- 没有性能陷阱，时间复杂度 O(n)，但实际只扫描首尾，不遍历全部
为什么 strings.TrimSpace 有时像没起作用？
最常见原因是：你以为的“空格”根本不在首尾。比如 "hello \n " 看似结尾有换行和空格，但如果你是从 JSON 或 HTTP Header 里读出来的，可能末尾还藏着一个 \r（Windows 风格换行），而 TrimSpace 会把它一并去掉——所以你反而看不出效果，以为失效了。
另一个高频坑是：你用 fmt.Scanln 或 bufio.Scanner 读输入，默认会丢掉末尾换行，但若手动拼接字符串或从二进制数据解析，就可能混入不可见控制字符。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 调试时用
fmt.Printf("%q", s)查看真实字符（比如"hello\u00a0"显示为"hello\xa0"） - 不要依赖肉眼判断空白，尤其处理用户输入、API 响应、日志行时
- 如果明确只要 ASCII 空格和制表符，用
strings.Trim(s, " \t")更可控
需要只去左边或右边？别硬套 TrimSpace
strings.TrimSpace 没有单侧版本。强行用它再补截断，既啰嗦又易错。Go 标准库提供了更直接的替代：
- 只去左边空白 →
strings.TrimLeftFunc(s, unicode.IsSpace) - 只去右边空白 →
strings.TrimRightFunc(s, unicode.IsSpace) - 如果只是去 ASCII 空格和 tab，用
strings.TrimPrefix/strings.TrimSuffix不合适（它们匹配前缀/后缀子串，不是字符集），该用strings.TrimLeft(s, " \t")
注意：TrimLeftFunc 和 TrimRightFunc 接收函数，每次调用都会执行判断，比 TrimSpace 稍慢一点，但绝大多数场景无感知。
和 Trim / TrimPrefix 混用时的兼容性注意点
strings.TrimSpace 和 strings.Trim 行为不同：Trim 只按给定字符集删首尾，不识别 Unicode 空白；而 TrimSpace 是专用逻辑，和 unicode.IsSpace 绑定。这意味着：
- 在 Go 1.0+ 所有版本中，
TrimSpace行为稳定，不会因 Unicode 版本升级突然多删某个字符 - 但如果你写
strings.Trim(s, " \t\n\r\f\v")，漏了某些 Unicode 空白（比如\u2000～\u200F），就和TrimSpace结果不一致 -
TrimPrefix和TrimSuffix是精确匹配字符串，不是字符集，传" "只能去一个空格，不能去多个，也不能去\t
真正容易被忽略的是：当你要做「先去首尾空白，再检查是否为空」时，别写 len(strings.TrimSpace(s)) == 0，直接用 strings.TrimSpace(s) == ""——前者在含大量空白的超长字符串上多一次长度计算，虽微小但没必要。
