strings.split 会保留空字符串元素。分隔符在开头、中间连续或结尾时均生成空字符串，如 strings.split("a,,b", ",") 返回 ["a", "", "b"]；空分隔符会 panic，空输入返回 [""]；需手动过滤空项或预处理换行符。
strings.Split 会把空字符串当有效元素吗
会。只要分隔符出现在开头、中间连续或结尾，strings.Split 就原样保留空字符串元素。比如 strings.Split("a,,b", ",") 返回 []string{"a", "", "b"}；strings.Split(",a", ",") 返回 []string{"", "a"}；strings.Split("a,", ",") 返回 []string{"a", ""}。
这在解析日志行、CSV 字段或配置项时特别容易踩坑：取 parts[1] 前不检查 len(parts) > 1，运行时直接 panic；或误把空字段当成“缺失”，其实它语义上表示“此处有分隔但无内容”。
- 需要过滤空字符串时，别用
strings.Fields——它只认空白字符（' '、'\t'、'\n'），且强制跳过所有空项，不适用于自定义分隔符 - 安全写法是显式遍历：
for _, s := range parts { if s != "" { ... } } - 若高频调用，可封装成函数，避免每次重复逻辑
空分隔符或空输入字符串会怎样
strings.Split(s, "") 会 panic：运行时报 panic: strings: Split: empty string separator。这不是设计疏漏，而是明确拒绝模糊语义——空分隔符无法定义“切在哪”，Go 不做猜测。
但空输入字符串是合法的：strings.Split("", ",") 返回 []string{""}（长度为 1 的切片，含一个空字符串），不是空切片 []string{}。这点常被忽略，导致后续逻辑对切片长度判断出错。
- 如果真要按字符拆分（如中文、emoji），必须用
strings.ToRuneSlice或手动遍历rune，Split不支持 - 多字节分隔符（如
":::"、" | "）完全没问题，sep是字符串，不是单字符 - 不要尝试用
string(rune)动态构造分隔符，除非你确定编码路径干净；直接写字符串字面量最稳妥
换行符和末尾分隔符怎么处理才不产生垃圾空项
读文件时每行带 \n 或 \r\n，直接 strings.Split(line, "\n") 很可能让最后一项变成空字符串，尤其当文件以换行结尾时。这不是 Split 的 bug，而是它忠实反映原始结构的结果。
更可靠的模式是预处理换行符：strings.TrimRight(line, "\r\n") 再 Split；或者统一用 strings.SplitN(line, "\n", 2) 控制分割次数，避免把路径里的换行也切开。
-
strings.SplitN(s, sep, n)中n > 0表示最多执行n-1次分割，结果长度 ≤n；n == -1等价于普通Split - 解析 HTTP 请求行这类“前两空格分三段”的场景，
SplitN(s, " ", 3)比盲目Split更健壮 -
bufio.Scanner默认去掉换行，但它和Split是两层抽象，别混为一谈
性能敏感场景下还能怎么优化
对百万级日志行做 strings.Split，热点往往不在算法本身，而在内存分配：每次调用都新建切片，小字符串反复触发 GC。
如果你知道最大字段数（比如固定 5 字段的 CSV），可预分配切片并复用；或改用 strings.Index + slice 手动截取，绕过切片扩容逻辑；极端情况甚至用 strings.Replacer 预处理掉干扰分隔符。
-
strings.FieldsFunc适合多分隔符且需 rune 级判断（如','或';'），但比Split略慢，因要调用函数 - 正则
regexp.Split灵活但重，仅当模式复杂（如[\s,]+）且无法用简单组合覆盖时才考虑 - 永远别在 hot path 上用
fmt.Sprintf构造分隔符再传给Split—— 字符串拼接成本远高于预期
Split，而是忘了它不做任何清洗、不猜意图、不替你做业务判断。空字符串、末尾换行、分隔符重叠——这些不是缺陷，是它的契约。你得主动应对，而不是等 panic 发生后翻文档。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
