strings.splitafter在每次匹配分隔符后立即切分并将分隔符“粘”在前一个片段末尾，如splitafter("a,b,c", ",")返回["a,", "b,", "c"]；空分隔符panic，无匹配时返回原字符串单元素切片。
strings.SplitAfter 不保留分隔符本身，它把分隔符“附着”在每个分割结果的末尾——这是最常被误解的一点。
为什么 strings.SplitAfter 分出来的结果看起来“多了一截”？
它不是“保留分隔符后分割”，而是“在每次匹配到分隔符后立即切一刀，把分隔符算进前一个片段”。比如 strings.SplitAfter("a,b,c", ",") 得到 []string{"a,", "b,", "c"}，最后一个元素没分隔符是因为后面没匹配到。
- 分隔符必须是完整子串，不支持正则（想用正则得换
regexp.Split） - 空字符串作为分隔符会 panic：运行时直接报
panic: strings: SplitAfter with empty string argument - 如果输入字符串不含分隔符，返回原字符串组成的单元素切片：
strings.SplitAfter("hello", "-") → []string{"hello"}
strings.SplitAfter 和 strings.Split 的关键差异在哪？
两者都按首次左到右匹配切分，但处理分隔符的方式不同：
-
strings.Split("x:y:z", ":")→[]string{"x", "y", "z"}（分隔符被丢弃） -
strings.SplitAfter("x:y:z", ":")→[]string{"x:", "y:", "z"}（分隔符“粘”在前面） - 性能上几乎无差别，底层都是遍历+切片；但
SplitAfter多一次子串拼接（实际是 slice head 移动，开销极小）
什么场景下该用 strings.SplitAfter？
典型用途是做“带标记的粗粒度解析”，比如拆解简单协议头、日志行前缀、INI 风格键值对（但注意不能处理引号包裹的含分隔符值）：
- 解析形如
"Content-Type: application/json\r\nAccept: */*\r\n"的 HTTP header 块（用\r\n分割，保留换行便于后续 trim） - 按冒号拆配置项但需知道哪段属于哪个 key：
strings.SplitAfter("name: Alice, age: 30", ", ")→["name: Alice, ", "age: 30"] - 和
strings.TrimSpace配合使用更安全：for _, s := range strings.SplitAfter(data, "\n") { fmt.Println(strings.TrimSpace(s)) }
真正容易被忽略的是边界情况：连续分隔符（如 "a,,b"）会被当作独立匹配，SplitAfter("a,,b", ",") 返回 []string{"a,", ",", "b"} —— 中间那个 "," 是合法结果，不是 bug。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
