strings.Split 和 strings.Join 易因空字符串、重复分隔符或 Unicode 边界出错；Split 连续分隔符产生空段，Join 不恢复原始格式，需谨慎用于 round-trip 场景。
Go 的 strings.Split 和 strings.Join 看似简单，但实际用时容易因空字符串、重复分隔符或 Unicode 边界出错。
strings.Split 会把连续分隔符当成多个空段
比如用 " " 拆分 "a b"（两个空格），结果是 []string{"a", "", "b"}，不是你想要的 {"a", "b"}。
常见于日志行解析、CSV 手动解析等场景。若原始字符串含多余空白，直接 Split 会导致 slice 中混入空字符串。
- 先用
strings.Fields替代 —— 它按任意空白字符切分并自动丢弃空段 - 若必须用
Split，后续加过滤：parts := strings.Split(s, " ") filtered := make([]string, 0, len(parts)) for _, p := range parts { if p != "" { filtered = append(filtered, p) } } - 注意：对 Unicode 字符（如中文、emoji）也安全，
strings.Split是按 UTF-8 字节切分，不是按 rune；但只要分隔符本身是合法 UTF-8，结果不会乱码
Split 后的空字符串在 Join 时不消失，但可能被误判为“没拆开”
如果 Split 出了 ["a", "", "b"]，再用 Join 回去就是 "a b"（中间一个空格），看起来像“恢复了”，其实语义已变——原字符串可能是 "a b"（两个空格）。
立即学习“go语言免费学习笔记（深入）”；
这在配置拼接、路径组装、SQL 拼接等场景容易埋坑。
- 不要假设
Join(Split(x, sep), sep)一定等于x - 若需保真 round-trip，改用
strings.SplitN(x, sep, -1)（行为一致），但依然不解决空段问题 - 更稳妥的做法：用
strings.Index+strings.TrimPrefix手动解析，或引入regexp.Split处理复杂分隔逻辑
Join 的性能比字符串拼接高，但只适用于已知 slice
strings.Join 底层预估总长度并一次性分配内存，比循环 += 快得多，尤其对大 slice。
但它要求你已有完整 []string，不能边生成边拼接。
- 若数据来自流式处理（如逐行读文件），用
strings.Builder更合适：var b strings.Builder for _, s := range lines { if b.Len() > 0 { b.WriteString(",") } b.WriteString(s) } result := b.String() -
Join对空 slice 返回空字符串，对 nil slice 会 panic —— 使用前检查是否为nil - 分隔符可以是任意字符串，包括空字符串
""（此时效果等价于strings.Concat）
真正麻烦的不是函数怎么写，而是你得时刻判断：这个字符串是不是用户输入？有没有隐藏空格？分隔符会不会出现在内容里？比如用 "|" 拆分日志，而日志内容本身含 |，那就该换 csv.NewReader 或加转义，而不是硬套 Split。
