bufio.Reader.ReadString 有时读不到完整行，是因为它只扫描到第一个分隔符就返回，不处理末尾无换行符的行、临时错误或缓冲区错乱；混用 ReadString 和 Read 会导致偏移错位，而 Scanner 更健壮但有64KB单行限制。
bufio.Reader.ReadString 为什么有时读不到完整行？
因为 ReadString 只保证读到第一个指定分隔符（如 '\n'）就返回，不关心后续内容是否还有更多换行符；它内部会从缓冲区逐字节扫描，一旦命中就切分并消费掉该分隔符——但若缓冲区已空、底层 io.Reader 又没立刻返回新数据，就会提前返回部分结果或报错。
常见错误现象：ReadString('\n') 返回的 line 末尾没有换行符（正常），但偶尔返回空字符串或只读到半行，通常是因为：
- 文件最后一行没以
\n结尾，ReadString遇到io.EOF后直接返回已读内容（无错误） - 底层 reader（如网络连接）返回了临时错误（
io.ErrTemporary），ReadString不重试，直接返回当前缓冲区内容 + 错误 - 你混用了
ReadString和Read，导致缓冲区位置错乱（见下文）
混合调用 ReadString 和 Read 会导致读取长度骤降
bufio.Reader 的所有读方法共享同一缓冲区和读取偏移量。当你先调用 ReadString('\n')，它会一路扫到换行符，并把偏移推进到换行符之后；此时缓冲区剩余空间可能只剩几百字节——紧接着调用 Read(buf)，就只能从这残余缓冲区里拷贝，哪怕你给的 buf 是 32KB，也只返回几百字节。
这不是 bug，是设计使然。关键点：
立即学习“go语言免费学习笔记（深入）”；
-
ReadString是“贪婪扫描”，会预消耗缓冲区中未交付的数据 -
Read是“按需填充”，只拿当前缓冲区里有的，不主动触发新系统调用去填满buf - 不要在同一个
bufio.Reader实例上交替使用ReadString和Read，尤其不能指望Read每次都填满你传入的切片
bufio.Scanner 为何比 Reader.ReadString 更适合通用行读取？
bufio.Scanner 封装了 ReadLine 的全部复杂性：自动处理 \r\n、正确拼接 isPrefix 情况、统一错误出口。而 ReadString 要求你手动判断 err == io.EOF 和 err == nil 的边界，稍有疏忽就漏掉最后一行。
但 Scanner 有硬限制：
- 默认单行最大 64KB，超长就报
scanner: token too long，且Scan()直接返回false，不提示哪一行出问题 - 必须显式调用
scanner.Err()检查错误，否则静默失败 - 如果要保留换行符，不能用
scanner.Text()，得用自定义SplitFunc或退回到reader.ReadBytes('\n')
缓冲区大小设置不是越大越好
bufio.NewReaderSize(file, 1024*1024) 设成 1MB 看似能减少系统调用，但实际收益取决于使用模式：
- 读小日志行（平均 100B）：4KB 缓冲区已足够，再大只是浪费内存
- 读超长 CSV 行（>500KB）：需要配大缓冲区，但更要配合
scanner.Buffer(make([]byte, 64*1024), 1 设置最大令牌长度 - 底层 reader 是
gzip.Reader或网络流时：缓冲区再大，也受限于解压后可用字节数或网络包大小，Read仍可能只返回几 KB
真正影响性能的是“单位时间内系统调用次数”，不是缓冲区绝对大小。4KB 对大多数文本场景已是合理起点。
