bufio.scanner默认单行限64kb，遇超长行直接panic且无法定位错误位置；应改用bufio.reader.readstring('\n')配合seek实现字节级断点续读，并手动控制缓冲区与内容校验。
为什么不能直接用 bufio.Scanner 处理超大文件
它默认限制单行长度为 64KB，遇到长日志、JSON 行或意外换行缺失时会直接 panic：scanner: token too long。更麻烦的是，它内部缓冲区不可控，一旦出错就无法获知已读位置，根本没法做“断点续处理”。
真正需要的是可定位、可重入、不丢行的逐行读取——bufio.Reader 才是可控起点：
- 用
reader.ReadString('\n')替代scanner.Scan()，错误时能明确知道卡在哪一行偏移 - 通过
reader.Size()和file.Seek()记录/恢复读取位置，实现真正的“行级断点” - 手动控制缓冲区大小（比如
bufio.NewReaderSize(file, 1024*1024)），避免小缓冲导致频繁系统调用
如何安全地记录和恢复行处理位置
关键不是记“第几行”，而是记“字节偏移”。因为文件可能被追加、截断或编码不一致，行号极易失准；而 os.File.Seek() + reader.Read() 组合能精准锚定到任意位置。
实操建议：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 每次成功处理完一行后，调用
file.Seek(0, io.SeekCurrent)获取当前偏移，存入本地状态文件（如 JSON 或纯文本） - 重启时先
file.Seek(offset, io.SeekStart)，再用reader.Reset(file)重建 reader，避免旧缓冲干扰 - 务必在写入状态前先
os.Sync()状态文件，否则崩溃可能导致 offset 滞后于实际处理进度
遇到空行、超长行、编码异常怎么办
真实日志或导出文件常含非标准内容：BOM 头、混合 \r\n/\n、UTF-8 截断、二进制垃圾。硬切 '\n' 会错切或卡死。
稳妥做法是分层处理：
- 用
reader.ReadBytes('\n')而非ReadString，它返回[]byte，允许你检查末尾是否真有换行（比如最后一批数据没换行） - 对每行先做
bytes.TrimRight(line, "\r\n")，统一换行符；再用utf8.Valid(line)判断是否可解码，否则跳过或转成 hex dump 存档 - 设置单行最大容忍长度（如 10MB），超过则主动丢弃并记录警告——防止某条坏数据阻塞整个流程
并发处理多行时如何避免状态混乱
别直接把 *os.File 或 *bufio.Reader 传给 goroutine 并发读——它们不是线程安全的，Seek 和 Read 会互相覆盖位置。
正确路径只有一条：预划分 + 单协程读 + 工作池分发
- 用
file.Stat().Size()获取总大小，按固定字节数（如 1MB）粗略切分“逻辑块”，但**不在块边界处强行切行** - 主线程顺序读，每读到完整一行就 send 到
chan []byte；worker goroutine 只负责解析/转换/入库，不碰文件指针 - 如果必须多文件并发（如轮询多个日志目录），确保每个
*os.File独占一个 goroutine，且各自维护独立 offset 文件
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
