是，bufio.Scanner读超长行会panic；需显式调用scanner.Buffer()设上限（如1MB），避免设math.MaxInt32致OOM，且必须检查scanner.Err()。
bufio.Scanner 读超长行直接 panic？调 Buffer 是唯一解
默认 bufio.Scanner 缓冲区上限是 64KB，遇到带 base64、嵌套 JSON 或大段二进制编码的日志行，scanner.Scan() 会返回 scanner: token too long 错误——这不是文件太大，是单行撑爆了缓冲区。
- 必须用
scanner.Buffer()显式设上限，例如支持最长 1MB 行：scanner.Buffer(make([]byte, 64*1024), 1024*1024) - 别设成
math.MaxInt32：万一输入缺换行符，会尝试分配数 GB 内存，直接 OOM -
scanner.Text()返回的字符串底层复用缓冲区，下一次Scan()就覆盖；若需长期保存（如存入 map 或切片），必须显式拷贝：string(scanner.Bytes())或append([]byte{}, scanner.Bytes()...)
bufio.Reader.ReadString('\n') 为什么有时比 Scanner 更稳？
当你要控制换行符边界、处理非标准格式（比如 \r\n 混用）、或需要在读取后回退时，bufio.Reader 是更可靠的选择——Scanner 把错误类型和底层行为都封装掉了。
- 用
reader.ReadString('\n')适合纯 Unix 风格日志；但注意它仍会为超长行分配大量内存，不如reader.ReadBytes('\n')安全（后者返回[]byte，不触发 UTF-8 解码） - 初始化时建议指定缓冲大小：
bufio.NewReaderSize(file, 16*1024)，尤其处理 CSV/JSON 行平均达 10KB 的场景 - 若文件被
Seek()过，必须调reader.Reset(file)刷新缓冲区，否则下次读先吐缓存旧数据，逻辑错乱
为什么 bufio.NewReader 比 os.File.Read 快？不是“加层”，是批量 syscall
直接用 os.File.Read 处理大文本，每行一次系统调用，10 万行就是 10 万次内核切换；bufio.NewReader 在用户态维护一块缓冲区（默认 4096 字节），一次 syscall 读入多字节，后续操作直接从内存取——摊薄了 syscall 成本。
- 它不减少总 I/O 量，只减少调用次数；对小文件或单次读完的场景提升有限
- 缓冲区不是越大越好：过大会浪费内存，过小则频繁重填；平均行长 200 字节 → 4KB 足够；CSV 单行常达 10KB → 建议 16KB
- 并发读同一
*os.File时，每个 goroutine 必须用独立的Reader实例，否则共享文件 offset + 各自缓冲 = 数据错位
bufio.Writer 写完文件为空？大概率忘了 Flush
bufio.NewWriter 的缓冲区只在三种情况下真正落盘：缓冲区满、显式调用 Flush()、或 writer 被关闭。忘记 Flush() 是“写完了但文件空”“程序退出后内容消失”的头号原因。
- 不能只靠
defer w.Close()：虽然Close()会调Flush()，但若失败（比如磁盘满），错误会被吞掉 - 更稳妥的收尾方式：
defer func() { w.Flush(); f.Close() }() - 缓冲区大小建议 32KB–256KB；写入前用
w.Reset(f)可复用已分配内存，避免反复 new
缓冲机制本身不改变语义，但改变了数据可见时机。最容易被忽略的是：错误检查必须用 scanner.Err() 或 reader.ReadString 的 err 判断，而不是仅看 Scan() 返回 false —— 后者可能是 EOF，也可能是真实错误。
