bufio.Scanner默认仅支持单字节分隔符（如\n），无法识别多字节边界（如"\r\n\r\n"或"--boundary"），因其底层依赖ReadBytes且切分逻辑固定；可靠方案是用bufio.Reader手动累积并bytes.HasSuffix匹配。
bufio.Scanner 默认按行切分，但不支持自定义多字节分隔符；真要读到特定字符串（比如 "\r\n\r\n" 或 "--boundary"），得绕过 Scanner，用 bufio.Reader 手动累积并匹配。
为什么 Scanner.Text() 不能可靠读到任意字符串边界
bufio.Scanner 的 Scan() 只能按单字节分隔符（如 '\n'）切分，内部用的是 ReadBytes，无法识别多字节序列。比如 HTTP header 和 body 之间的 "\r\n\r\n"，或 multipart 表单中的 "--boundary"，Scanner 会把它拆成几段，导致解析错乱。
- 调用
scanner.Text()后，下一次Scan()会覆盖缓冲区 —— 你拿不到“上一行末尾 + 下一行开头”拼起来的完整边界 -
scanner.Bytes()虽返回字节切片，但仍是按行截断的，不保证跨行连续性 - 即使调大
scanner.Buffer()，也只影响单行长度上限，不改变切分逻辑
用 bufio.Reader 实现“读到指定字符串”
核心是边读边查后缀：每次读一块，追加到缓冲区，检查末尾是否匹配目标分隔符。不依赖换行，也不预分配过大内存。
- 初始化
reader := bufio.NewReader(file)，再准备一个 growablebuf := make([]byte, 0, 4096) - 循环调用
reader.ReadBytes('\n')或reader.ReadByte()都太低效；推荐用reader.Read()填满固定 buffer，再拷贝进buf - 每次追加后，用
bytes.HasSuffix(buf, delim)检查 —— 注意delim是[]byte，不是string - 匹配成功时，截取
buf[:len(buf)-len(delim)]即为目标内容；别忘了把 reader 位置回退（用reader.UnreadByte()或重置内部状态） - 如果文件结尾没匹配到分隔符，需判断是 EOF 还是数据不完整 —— 此时
err == io.EOF且len(buf) > 0，按业务决定是否报错
常见坑：缓冲区管理与内存泄漏
手动拼接 buf 容易失控。几百 MB 的文件若一直 append 不清理，一样 OOM。
立即学习“go语言免费学习笔记（深入）”；
- 不要无限制
buf = append(buf, chunk...)；对超长内容（比如 multipart 中超大附件），应改用流式处理 —— 匹配到分隔符后，直接把后续数据交给另一个io.Copy处理 -
bufio.Reader自身有默认缓冲区（4KB），但Read()返回的n可能小于len(buf)，必须用chunk[:n]截取有效部分 - 别在循环里反复
make([]byte, 4096)—— 提前声明一次复用，避免 GC 压力 - 如果分隔符本身含
\x00或非 UTF-8 字节，bytes.HasSuffix仍能正常工作，但后续转string会出问题；二进制场景一律用[]byte操作
真正难的不是“怎么读到某个字符串”，而是“读到之后，怎么继续安全地读下去”。很多协议要求分隔符后紧跟新数据块，这时必须确保 reader 内部偏移和外部缓冲区完全对齐 —— 错一位，后面全乱。
