必须传符合func(data []byte, ateof bool) (advance int, token []byte, err error)签名的函数；它是逐块解析驱动逻辑，需正确处理ateof、advance和token以避免丢数据或卡住。
bufio.NewScanner 的 SplitFunc 参数怎么传
必须传一个符合 func(data []byte, atEOF bool) (advance int, token []byte, err error) 签名的函数。这不是回调钩子，而是逐块解析的驱动逻辑——bufio.Scanner 每次读一块数据（默认 64KB），交给你决定“哪部分算一个 token”，然后挪动指针继续。
常见错误是直接返回 data 全量或忽略 atEOF：这会导致最后一段没换行的数据被丢弃，或反复切出空 token。
实操建议：
- 始终检查
atEOF：为真时，若还有未分隔的剩余数据（比如最后一行没\n），应将其作为最终 token 返回 -
advance必须是「从当前 data 起始位置，要跳过的字节数」；若返回 0 且token == nil，Scanner 会认为无新 token，可能卡住 - 不要在 SplitFunc 内修改
data底层数组，Scanner 后续还会复用这块内存
实现按双换行符（\r\n\r\n）分割 HTTP 报文头
HTTP 响应头与 body 之间用空行分隔，但标准 bufio.ScanLines 只认单行，得自己写 SplitFunc。
关键点在于：不能只找第一个 \r\n\r\n 就停，要确保它后面紧跟非空白字符（避免把 body 中的空行误判为分隔符）——但 Scanner 的 SplitFunc 不知道后续内容，所以只能保守处理：找到首个 \r\n\r\n 即切，由上层逻辑判断 token 是否合法。
示例：
func httpChunkSplit(data []byte, atEOF bool) (advance int, token []byte, err error) {
if atEOF && len(data) == 0 {
return 0, nil, nil
}
// 查找 \r\n\r\n
i := bytes.Index(data, []byte("\r\n\r\n"))
if i
<p>注意：<code>bytes.Index</code> 是安全的，哪怕 <code>data</code> 长度不足 4 字节也不会 panic；但若你用 <code>data[i:i+4]</code> 做判断，必须先检查长度。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/ai/2187" title="蛙蛙写作——超级AI智能写作助手"><img
src="https://img.php.cn/upload/ai_manual/001/246/273/68b6c6e349825299.png" alt="蛙蛙写作——超级AI智能写作助手" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/ai/2187" title="蛙蛙写作——超级AI智能写作助手" class="overflowclass">蛙蛙写作——超级AI智能写作助手</a>
<p class="overflowclass">一款AI视频创作工具，主要用于蛙蛙写作辅助AI写文，帮助获取创意灵感，提供拆书、小说转剧本、视频生成等功能，是一款功能全面的AI智能写作工具，适合需要提升相关任务效率的用户。</p>
</div>
<a rel="nofollow" href="/ai/2187" title="蛙蛙写作——超级AI智能写作助手" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<h3>为什么自定义 SplitFunc 后 Scanner.Scan() 总返回 false</h3>
<p>最常见原因是 SplitFunc 在某次调用中返回了 <code>advance == 0</code> 且 <code>token == nil</code>，而 <code>atEOF == false</code>——Scanner 认为“没推进、也没产出”，直接放弃循环。</p>
<p>典型诱因：</p>
- 正则匹配或复杂查找逻辑里，没覆盖
len(data) 的情况，直接 return 0, nil, nil - 误把
atEOF当成“数据结束标志”，在atEOF == false时拒绝返回任何 token，哪怕已有完整分隔符 - 错误地返回负数
advance（Go 1.22+ 会 panic）
调试技巧：在 SplitFunc 开头加日志，打印 len(data)、atEOF 和返回值，尤其关注第一次调用后是否卡住。
性能和边界要注意什么
SplitFunc 被高频调用（每块数据至少一次），别在里面做耗时操作：比如开 goroutine、调用 regexp.Match、或反复 make([]byte, ...) 分配内存。
实际影响明显的点：
- 用
bytes.Index替代strings.Index（后者会隐式转string，触发额外内存分配） - 避免在 SplitFunc 内构建结构体或调用方法——token 提取出来后再处理
- 如果分隔符固定且短（如
"|"、"\t"），手写线性扫描比用bytes.Index略快，但可读性差，一般没必要 - Scanner 默认缓冲区 64KB，若你的 token 平均远大于此（如解析大 JSON 片段），要考虑调大
scanner.Buffer，否则会报bufio.Scanner: token too long
真正难的是状态保持——比如按缩进层级分割 Python 代码块，SplitFunc 无法跨块记住上一次的缩进数，这时该换 bufio.Reader 手动读取 + 状态机，而不是硬塞进 SplitFunc。
