别用 bufio.Scanner 处理超长文本文件，它默认 64KB 行长限制会 panic；应优先用 bufio.Reader.ReadString 或固定大小 file.Read() 分块处理。
直接结论：别用 bufio.Scanner 处理超长文本文件，它默认 64KB 行长限制会 panic；真要按需分块，优先用 bufio.Reader 手动控制读取边界，或干脆跳过“行”抽象，用固定大小 file.Read() 分块。
为什么 bufio.Scanner 在超长文本上容易 panic
bufio.Scanner 的设计目标是安全、简洁地处理常规文本行，不是为任意长度行服务的。它内部维护一个缓冲区，默认上限 64KB；一旦某一行（比如嵌入了 base64 图片或大段 JSON）超过这个长度，就会直接触发 panic: bufio.Scanner: token too long。
- 这不是 bug，是故意为之——防止内存失控
- 调大缓冲区（
scanner.Buffer(buf, max)）能缓解，但无法根治：你永远不知道下一行有多长 - 即使设成 10MB，遇到 50MB 的单行照样崩，而且内存分配不可控
- 它还会自动丢弃
\r、合并连续换行符，行为不透明，调试困难
bufio.Reader.ReadString('\n') 是更可控的替代方案
当你仍想保留“按行”语义，但必须应对长度不可控的文本时，bufio.Reader.ReadString 提供确定性边界控制：它只在遇到 \n 时返回，不预判长度，也不强制裁剪。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 返回的
line包含结尾的\n（或\r\n），需手动清理：strings.TrimRight(line, "\r\n") - 不会因行长爆炸而 panic，错误类型明确（
io.EOF或具体io.ErrUnexpectedEOF） - 跨平台换行兼容靠自己处理，反而更可靠——比如日志混用 Windows 和 Linux 换行时，Scanner 可能误吞
\r - 性能略低于 Scanner（少一层缓存优化），但稳定性高得多
真正超大文本（GB 级）应放弃“行”概念，改用固定块读取
当文件达到几十 GB，且每行长度波动极大（如混合日志+二进制 payload），按行解析本身就成了瓶颈：频繁 string 分配、GC 压力、UTF-8 解码开销都会拖慢速度。此时“分块”不是权宜之计，而是必要选择。
立即学习“go语言免费学习笔记（深入）”；
- 用
file.Read(buf)配合预分配的[]byte（如 1MB），复用缓冲区，避免 GC - 不假设换行存在，把解析逻辑下沉到块内状态机：扫描
\n位置、缓存跨块行尾、识别协议头等 - 注意处理块末尾截断的不完整行——保存剩余字节到下次读取前缀
- 若需并行，worker 必须复制块数据（
append([]byte{}, buf[:n]...)），否则共享底层数组会引发数据错乱
容易被忽略的关键点
很多人卡在“以为分块就是换个读法”，其实真正的难点在边界处理：跨块的换行、编码边界（尤其是 UTF-8 多字节字符被切开）、以及如何让下游逻辑不感知块的存在。用 bufio.Reader 时，ReadString 返回的 line 是完整字符串，但用 file.Read 时，你得自己保证 \n 不被截断——这需要状态保持，不是加个 if 就能解决的。
