go处理gb–tb级文件需流式+缓冲+显式控制：scanner默认64kb缓冲易panic，须用scanner.buffer()设合理上限（如1mb）并检查scanner.err()；超长行应改用bufio.reader.readbytes('\n')或循环read手动扫描；写入后必须显式flush，避免丢数据。
Go 语言处理极大规模文件（GB–TB 级）没有“银弹”，关键在于避开 os.ReadFile 和 os.WriteFile 这类全量内存加载接口，转而用流式 + 缓冲 + 显式控制的组合。否则不是慢，是直接 OOM 或卡死。
bufio.Scanner 读超长行会 panic？调缓冲区前先看错误源
scanner.Scan() 返回 true 不代表成功——它只表示“找到了下一个 token”，但可能刚读完就触发了 scanner: token too long。这个错误不会在 Scan() 中抛出，得查 scanner.Err()。
- 默认缓冲区仅 64KB，遇到带 base64 的日志行或未换行的 JSON blob，立刻失败
- 用
scanner.Buffer(make([]byte, 64*1024), 1024*1024)设上限为 1MB，别用math.MaxInt32（缺换行符时会尝试分配数 GB） -
scanner.Text()返回字符串底层复用缓冲区，下一轮Scan()就覆盖；需长期保存必须显式拷贝：string(scanner.Bytes())或append([]byte{}, scanner.Bytes()...)
bufio.Reader 比 Scanner 更适合协议解析和大块读取
当你要控制读取边界（比如 HTTP header/body 分界）、需要 Peek() 预览字节、或要跳过某段数据时，bufio.Scanner 的封装太深，连错误类型都藏起来了，bufio.Reader 是唯一选择。
- 初始化用
bufio.NewReaderSize(file, 1（1MB 缓冲区），比默认 4KB 更适配顺序读 - 读行优先用
reader.ReadBytes('\n')（返回[]byte，不触发 UTF-8 解码），比ReadString更可控 - 超长行风险仍在：若单行可能达几百 MB，应改用
reader.Read(buf)循环 + 手动扫描换行符，避免内存暴涨
写入大文件卡住或丢数据？Flush 不是可选项
bufio.NewWriter 的缓冲区只在三种情况下真正落盘：缓冲区满、显式调 w.Flush()、或 w.Close()。只靠 defer w.Close() 是危险的——如果 Close() 内部 Flush() 失败（如磁盘满），错误会被吞掉，文件内容就丢了。
- 写完必须手动
w.Flush()，并在 defer 中组合：defer func() { w.Flush(); f.Close() }() - 缓冲区大小建议 32KB–256KB；设太小（如 4KB）导致 syscall 过多，太大（如 100MB）失去流控意义且延迟暴露错误
- 不要把
w包在闭包里长期持有——未 Flush 的缓冲区会一直占内存，GC 也清不掉
内存还是高？检查是否无意保留了底层切片引用
Go 的 GC 不会主动把内存还给操作系统，尤其当你无意中保留了 bufio.Scanner.Bytes() 或 reader.Read() 返回的 []byte 引用时，整块缓冲区都会被钉住。
- 常见陷阱：
append(mySlice, scanner.Bytes()...)—— 这不是拷贝，是共享底层数组 - 正确做法：
data := append([]byte(nil), scanner.Bytes()...)或直接用scanner.Text() - 处理完一批数据后，手动置空局部切片：
buf = buf[:0]，帮助编译器识别可复用空间
最易被忽略的一点：别对单个大文件盲目开 goroutine 分段读。磁盘 I/O 是顺序设备，SSD 上并发读同一文件常比串行还慢——寻道和缓存竞争带来的开销，远超 CPU 并行收益。真要并发，只适用于多个独立大文件，或读完后计算密集型任务。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
