读大文件应避免os.ReadFile以防OOM，需匹配缓冲区大小、复用方式与读取模式：顺序读日志用32KB–64KB缓冲，Scanner需设Buffer防超长行，二进制流用8KB–16KB；scanner.Bytes()返回引用需显式拷贝，sync.Pool仅在高频短任务中有效，随机读大文件且内存充足时可选mmap。
别用 os.ReadFile 读大文件，它会直接 OOM；真正高速读取靠的是缓冲区大小、复用方式和读取模式三者匹配，不是越大越好，也不是越并发越快。
缓冲区大小设多少才不拖慢也不爆内存
默认 4KB 缓冲对小文件够用，但读几百 MB 日志时，系统调用太频繁，吞吐上不去；设成 100MB 又浪费内存、延迟错误暴露、还可能卡住 GC。
- 顺序读文本（如日志）：32KB–64KB 最稳，
bufio.NewReaderSize(f, 64*1024)能平衡 syscall 次数与响应延迟 - 逐行用
Scanner：必须调scanner.Buffer(make([]byte, 64*1024), 1024*1024)，否则超长行（比如含 base64 的日志）直接报scanner: token too long - 二进制流式解析（如协议头+payload）：用
bufio.NewReader配合Peek/Discard，缓冲区 8KB–16KB 更利于控制边界 - 实测中，从 4KB 提到 64KB，GB 级日志解析耗时下降约 40%，再提至 1MB 改善微乎其微，但内存峰值翻倍
为什么 scanner.Bytes() 一存就内存下不来
它返回的是底层缓冲区的切片引用，不是拷贝。只要这个 []byte 还在 map 或 slice 里，整块缓冲区（比如 64KB）就一直被 GC 认为“活着”，哪怕你只想要其中 100 字节。
- 要长期保存某行内容，必须显式拷贝：
data := append([]byte(nil), scanner.Bytes()...)或string(scanner.Bytes()) - 更轻量的做法是改用
scanner.Text()—— 它内部已做拷贝，返回字符串，底层数组可被立即回收 - 如果批量处理后要复用缓冲（比如循环读多个文件），记得手动清空局部切片：
buf = buf[:0]，帮编译器识别可重用空间
用 sync.Pool 复用缓冲区真能提速吗
能，但只在高频、短生命周期场景下显著——比如一个服务每秒打开/关闭上百个日志文件，或并发解析数千个小分片。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
立即学习“go语言免费学习笔记（深入）”；
- 定义池时别直接存
[]byte，而应存指针：sync.Pool{New: func() interface{} { b := make([]byte, 64*1024); return &b }}，避免每次Get()后还要make - 使用时解引用：
reader.Read(*bufPtr)，确保写入预分配空间 - 注意：单个大文件只开一次 reader 时，池没意义；反而增加跳转开销。池的价值在于“大量相似短期任务”
- 别忘了归还：
defer pool.Put(bufPtr)，漏掉会导致缓冲区泄漏，内存缓慢上涨
什么时候该放弃 bufio，换 mmap
当你需要随机跳转读取（比如查索引、定位偏移 2.3GB 处的记录），且文件只读、内存充足、平台可控时，mmap 才值得上。
-
bufio是流式顺序搬运工，mmap是把文件“请进内存当本地数组用”——前者省系统调用，后者省内核拷贝 - 用
github.com/edsrzf/mmap-go比原生syscall.Mmap更安全，自动处理页对齐和 Windows 兼容 - 映射后不能直接
unsafe.Slice(mmap, size)就完事：需检查文件长度、处理截断风险、读完调mmap.Unmap() - 别在容器或内存受限环境硬上 mmap；几十 GB 文件映射失败不报错，而是静默退化成普通读，极难排查
最常被忽略的一点：所有缓冲优化都建立在“不保留无关引用”的前提下。哪怕缓冲区设得再合理，只要某个 []byte 被闭包捕获、塞进全局 map、或作为 struct 字段长期存活，那块内存就永远归不还操作系统——GC 不负责还给 OS，只负责标记是否可回收。
