strings.Split 会将空字符串作为有效元素，如 strings.Split("a,,b", ",") 返回 ["a", "", "b"]；strings.SplitN 可限制分割次数，避免末尾字段被误拆。
strings.Split 会把空字符串也当有效元素吗
会。只要分隔符出现在开头、结尾或连续出现，strings.Split 就会产生空字符串元素。比如 strings.Split("a,,b", ",") 返回 []string{"a", "", "b"}；strings.Split(",a", ",") 返回 []string{"", "a"}。
这在解析 CSV 或日志行时容易引发越界 panic（比如取 parts[1] 前没检查长度），也常被误认为“分割失败”。
- 需要过滤空字符串时，手动遍历 +
len(s) > 0判断最稳妥 - 若只想要非空切片，可封装一层：
filterEmpty := func(ss []string) []string { var res []string; for _, s := range ss { if s != "" { res = append(res, s) } }; return res } -
strings.Fields是替代方案，但它按任意空白字符（空格、\t、\n）切割且自动跳过空项，不适用于自定义分隔符
Split 和 SplitN 的关键区别在哪
strings.Split 拆出全部子串；strings.SplitN 可控制最多拆出几段，剩余部分保留在最后一个元素里。这对解析固定格式但末尾字段含分隔符的场景很关键。
例如解析 HTTP 请求行 "GET /path?k=v&x=y HTTP/1.1"，想按空格拆成方法、路径、协议三部分，但路径本身可能含空格（虽不规范，但真实日志里存在）：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
parts := strings.SplitN(line, " ", 3) // 最多拆 2 次，得 3 个元素
if len(parts) != 3 {
// 格式错误
}
method, path, proto := parts[0], parts[1], parts[2]
-
n > 0：最多执行n-1次分割，结果切片长度 ≤n -
n == 0：等价于Split（但不推荐这么用，语义不清） n ：不限制，等价于 <code>Split
中文或 Unicode 字符做分隔符要注意什么
strings.Split 按字节操作，不是按 rune。如果分隔符是多字节 UTF-8 字符（如中文顿号、全角逗号），必须确保传入的是完整 UTF-8 编码的字符串字面量，而不是单个 rune 强转。
错误写法：strings.Split(text, string('，')) —— '，' 是 rune，string(rune) 会正确转成 UTF-8 字节序列，看似可行，但易混淆；更危险的是误用 fmt.Sprintf("%c", '，') 等间接方式引入编码问题。
- 直接写字符串字面量最安全：
strings.Split(text, "，")或strings.Split(text, "｜") - 避免用
bytes.Split处理含中文的字符串，它只认字节，可能切在 UTF-8 中间导致乱码 - 若需按 Unicode 字符边界切分（如按 emoji 分割），得先用
strings.ToRuneSlice转 rune 数组再手动处理，Split不支持
性能敏感场景下 Split 有什么隐患
每次调用 strings.Split 都会分配新切片和底层数组，频繁调用（如每秒万次日志解析）可能触发 GC 压力。它内部没有复用缓冲区机制。
- 高频场景优先考虑预分配+
strings.Index循环查找，配合unsafe.Slice（Go 1.17+）或bytes.Buffer拼接，但复杂度上升 - 若分隔符固定且简单（如单字符），可用
strings.IndexByte替代strings.Index，性能高约 20–30% - 不要为了“省一次分配”而缓存
strings.Split结果切片并复用——底层数组可能被后续写操作污染，Go 切片共享底层数组的特性在此是陷阱
真正要抠这点性能，说明你已经卡在字符串处理上，这时候该看是不是能换结构（比如用 bufio.Scanner 流式读 + 预编译正则）或者改协议（避免用分隔符传复杂数据）了。
