go 的 bufio.scanner.split 是替换而非配置分隔逻辑，必须传入严格签名的 splitfunc 函数；需正确处理 ateof、零分配、越界防护及 advance 精确推进。
Go 的 bufio.Scanner.Split 不是配置，是替换驱动逻辑
你没法“配置”分隔符，只能用 Split() 方法传入一个全新函数，彻底接管 token 切分过程。默认的 bufio.ScanLines 只是其中一个实现，它不支持任何自定义符号（比如 "|||"、"\x00" 或双换行 \r\n\r\n）。一旦调用 scanner.Split(myFunc)，后续所有 Scan() 行为都由你写的函数决定。
常见错误是把它当成开关或参数：比如以为 scanner.Split(bufio.ScanWords) 是“启用单词模式”，其实它是把整个切分逻辑换成了另一个预设函数；而你要自定义，就必须写自己的 func(data []byte, atEOF bool) (advance int, token []byte, err error)。
- 函数签名必须严格匹配，少一个参数或类型不对，编译就报错
-
token是data的切片引用，不是拷贝——别在函数里改data底层内容 -
advance是从当前data[0]开始要跳过的字节数，不是 token 长度
写 SplitFunc 必须处理 atEOF 和不完整数据
最常漏掉的是 atEOF 分支，导致最后一段没分隔符的数据永远扫不到。比如输入 "a|||b|||c" 正常；但输入 "a|||b|||c"（末尾无 |||），若函数没检查 atEOF && len(data) > 0，就会直接返回 (0, nil, nil)，Scanner 卡住不动。
正确结构只有三步：
- 先找分隔符位置（如用
bytes.Index查"|||"） - 如果找到，返回
i+3（advance）、data[0:i]（token）、nil（err） - 如果没找到：
if atEOF { return len(data), data, nil }；否则return 0, nil, nil（告诉 Scanner 继续读）
漏掉最后这个 return 0, nil, nil，Scanner 会认为“没新 token 也没错误”，反复调用你的函数，实际卡死。
SplitFunc 性能关键：零分配 + 不越界
标准库的 ScanLines 和 ScanWords 都是零分配的——token 直接切 data，不 new 内存。你的函数也该如此。别写 string(data[0:i]) 或 append([]byte{}, data[0:i]...)，这会触发堆分配，对高频解析（如日志流）影响明显。
还要防 panic：做 bytes.Index 前先确认 len(data) >= 3（若分隔符长 3 字节），否则 Index 可能越界；或者用 bytes.Index 返回 -1 后再判断，而不是盲目切片。
缓冲区上限也要同步调：scanner.Buffer(make([]byte, 4096), 10*1024*1024)，否则超长 token（比如 base64 块）会直接报 bufio.ErrTooLong，跟你写的 SplitFunc 无关。
混用 nextLine() 和 Split()？别这么干
这是 Java Scanner 的坑，但 Go 里不存在 nextLine() 方法。不过有人误以为 Text() 就是“读一行”，然后在自定义 Split 后还手动按 \n 拆 Text() 返回值——这等于绕过自己写的逻辑，白写了。
真正要注意的是：如果你的 SplitFunc 返回的 token 包含换行符（比如按 \r\n\r\n 切 HTTP 报文，但 token 里仍有 \n），上层代码别假设它是“干净行”。是否需要再清洗、是否要保留原始换行，得由业务逻辑定，SplitFunc 只管切，不管语义。
最易被忽略的点：Scanner 内部状态机依赖 advance 精确推进指针。哪怕只差 1 字节，后续数据就会错位——比如分隔符是 "\r\n"，你返回 i+1 而不是 i+2，下一个 data 块开头就少一个 \n，整个解析崩掉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
