strings.TrimSpace 不处理中文全角空格（U+3000）等非ASCII空白符，因其仅识别Unicode定义的标准空白符；需手动扩展过滤逻辑才能兼容中文环境。
TrimSpace 为什么不能去掉中文全角空格
strings.TrimSpace 只处理 Unicode 定义的“空白符”（如 ' '、'\t'、'\n'、'\r'、'\v'、'\f'），不包含全角空格（ ，U+3000）、不间断空格（ ，U+00A0）或零宽空格（U+200B 等）。如果你从网页表单、Excel 或某些编辑器里读到字符串，常见现象是：strings.TrimSpace(" hello ") 返回 " hello " —— 看似没变。
解决办法不是换函数，而是明确需求：
- 若只要清理 ASCII 空白（标准协议/日志/命令行输入），
strings.TrimSpace完全够用 - 若需兼容中文环境或用户粘贴内容，得手动过滤特定码点，例如：
func TrimAllSpace(s string) string { return strings.Map(func(r rune) rune { switch r { case ' ', '\t', '\n', '\r', '\v', '\f', ' ', '\u00A0': return -1 // 删除 default: return r } }, s) }
TrimPrefix 和 TrimSuffix 比 TrimSpace 更精准但容易误用
strings.TrimPrefix 和 strings.TrimSuffix 不是“去空格”，而是按字面匹配前缀/后缀字符串。比如：strings.TrimPrefix("prefix_hello", "prefix_") → "hello"；但 strings.TrimPrefix("pre hello", "pre") → " hello" —— 注意它不关心后面是不是空格。
常见误用场景：
- 想删掉开头所有空格却写了
strings.TrimPrefix(s, " ")：只能删最前面一个空格，且只在首字符恰好是' '时生效 - 传入空字符串
""作为前缀：直接返回原串，无提示也不报错，容易埋下逻辑漏洞 - 大小写敏感：传
"ID:"去不掉"id:"，别指望它自动忽略
性能差异：TrimSpace vs 自定义 for 循环
对短字符串（strings.TrimSpace 和手写双指针循环几乎没差别；但对超长文本（如读取整个配置文件），strings.TrimSpace 是一次遍历 + 一次切片，而 strings.Map 类方案会新建字符串并逐字符判断，开销明显更高。
真要极致优化时，可考虑：
- 用
bytes.TrimSpace处理[]byte（避免 string → []byte 转换开销） - 如果确定只去首尾 ASCII 空格，手写双指针更可控：
func trimASCII(s string) string { start, end := 0, len(s) for start start && (s[end-1] == ' ' || s[end-1] == '\t' || s[end-1] == '\n' || s[end-1] == '\r') { end-- } return s[start:end] } - 注意：手写版本不处理 Unicode 组合字符（如带重音符号的字母），
strings.TrimSpace内部用unicode.IsSpace，更健壮
JSON Unmarshal 时字段自动 Trim 的陷阱
Go 的 json.Unmarshal 默认不会对字符串字段调用 TrimSpace —— 这是很多人踩坑的起点。比如 API 返回 {"name": " Tom "}，结构体字段仍是 " Tom "，不是 "Tom"。
补救方式有三种：
- 在 struct 字段上加自定义 UnmarshalJSON 方法（适合少数关键字段）
- 用中间类型转换，例如：
type User struct { Name string `json:"name"` } // 使用前：u.Name = strings.TrimSpace(u.Name) - 借助第三方库如
github.com/mitchellh/mapstructure配合 hook，但引入复杂度需权衡
真正容易被忽略的是：这种“自动清理”一旦加在某一层（比如 HTTP handler 入口统一 Trim），后续中间件或日志记录可能拿到已被修改的值，导致调试时字段和原始请求对不上。留个 // trimmed by handler 注释，比事后查半天强。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
