strings.Split 有严格行为边界：空分隔符 panic，空输入返回 [""]；连续分隔符保留空字段；末尾换行导致空项；结果字符串共享原底层数组，需手动拷贝防内存泄漏。
strings.Split 不是万能的切片工具，它按字面量精确匹配分隔符、不跳过空字段、对边界输入行为固定——用错场景或忽略细节，轻则逻辑出错，重则内存泄漏。
空分隔符会 panic，但空字符串输入不会
传入 "" 作 sep 时，Go 直接 panic：panic: strings: Split: empty string separator。这不是设计疏漏，而是明确拒绝模糊语义。但传入空字符串 s == "" 是合法的，返回 []string{""}（含一个空字符串），不是空切片。
常见误判：
- 把用户输入的分隔符未校验就直接传给
strings.Split，一旦为空就崩 - 以为
strings.Split("", ",")返回[]string{}，结果后续len()或遍历时 panic nil 指针
安全做法：调用前加判断
if sep == "" {
return nil // 或 error
}
parts := strings.Split(s, sep)
连续分隔符产生空字符串，不是 bug 是行为
strings.Split("a,,b", ",") 得到 []string{"a", "", "b"}，不是 {"a", "b"}。这是按“分隔符位置”切片的自然结果，和 POSIX shell 的 IFS 或 Python 的 str.split()（默认模式）不同。
立即学习“go语言免费学习笔记（深入）”；
典型踩坑场景：
- 解析 PATH：
":/usr/bin::/bin:"→["", "/usr/bin", "", "/bin", ""]，不清理就os.Stat会报stat : no such file - CSV 行首尾或中间多逗号，误当有效字段处理
过滤空字段要手动，且不能简单 strings.TrimSpace 后再 split——那会破坏原始字段内容（比如 " a , b " 去空格变 "a,b"，丢失了字段两侧空格语义）。稳妥方式是遍历后筛：
var clean []string
for _, s := range parts {
if s != "" {
clean = append(clean, s)
}
}
换行符末尾导致最后一项为空，别依赖 Scanner 隐式处理
读文件时若用 io.ReadAll 或 bufio.Reader.ReadString 拿到完整内容，末尾带 \n 或 \r\n，直接 strings.Split(buf, "\n") 会让最后一项变成空字符串。例如文件内容为 "line1\nline2\n"，结果是 ["line1", "line2", ""]。
原因：Split 不关心语义，只机械匹配。而 bufio.Scanner 默认去掉换行是扫描器自己的行为，和 strings.Split 无关。
推荐组合：
- 先
strings.TrimSuffix(line, "\n")再strings.Split(..., "\n") - 或统一用
strings.TrimRight(line, "\r\n")，兼容 Windows/Linux - 若只需取首行+余下，用
strings.SplitN(line, "\n", 2)，避免分配整块切片
大字符串只取一小段？小心底层内存逃逸
strings.Split 返回的每个 string 都共享原字符串底层数组。如果原字符串是几 MB 的日志内容，你只取其中第一个字段 parts[0]，只要这个字段变量还活着，整个日志内存就无法被 GC 回收。
高频或内存敏感场景（如解析超长 HTTP body、日志流）要主动断开引用：
part := string(append([]byte(nil), parts[0]...))
这行代码强制拷贝，让新 string 持有独立内存。别省这一步——它成本很低，但漏掉可能引发长期内存驻留。
真正容易被忽略的是：这种引用关系完全静默，没有编译警告，也不会立即 OOM，而是在压测或上线后缓慢堆积，排查成本极高。
