bufio.newreadersize 更适合大文件顺序读取，因其内部无锁复用缓冲区，避免 sync.pool 的锁开销；合理设置 32kb–256kb 缓冲可减少 syscall 次数，提升吞吐。
直接用 sync.Pool 复用 []byte 缓冲区，对单个大文件顺序读取几乎没收益，反而可能拖慢性能——因为 Get/Put 的锁开销在微秒级 I/O 中占比过高。
为什么 bufio.NewReaderSize 比 sync.Pool 更适合大文件顺序读
大文件流式读取的瓶颈通常是磁盘吞吐或系统调用频率，不是内存分配。bufio 已在内部复用缓冲区，且无锁；你只需控制大小、避免逃逸即可。
- 默认 4KB 缓冲太小：GB 级日志下
Read调用次数爆炸，CPU 花在 syscall 上而非处理数据 - 实测甜点区间是 32KB–64KB（SSD）或 256KB（机械盘/NFS），设为页大小（4KB）整数倍可避免内核对齐失败
- 别套多个
bufio.Reader到同一*os.File，读位置会错乱，数据直接丢 - 缓冲区太大（如 100MB）不提升吞吐，只延迟错误暴露、抬高内存峰值
scanner.Bytes() 返回的是引用，不是拷贝
scanner.Bytes() 直接返回底层缓冲区切片，只要这个值被存进 map、slice 或传给 goroutine，整块缓冲（比如 64KB）就无法被 GC 回收。
- 安全做法：需要长期保存时显式拷贝，
data := append([]byte(nil), line...) - 更轻量：优先用
scanner.Text()，它内部已做字符串拷贝，底层数组可立即释放 - 若批量处理后要复用缓冲，手动清空：
buf = buf[:0]，帮编译器识别可重用空间 - 超长行（如含 base64 的日志）必须提前调
scanner.Buffer(buf, maxLineLen)，否则 panic 报scanner: token too long
sync.Pool 只在特定高频短任务中有效
池的价值不在“复用”，而在“大量相似短期任务”下的 GC 压力缓解。对单个大文件读一次，池纯属多余。
- 适用场景：每秒并发打开/关闭数百个小文件（如日志分片），或固定大小大块读（≥1MB/次）且单 goroutine 高频调用
- 定义池时必须存指针：
return &b，避免每次Get后还要make - 使用时解引用：
n, err := file.Read(*bufPtr)，确保写入预分配空间 - 漏掉
Put会导致缓冲泄漏；传错类型（如传buf而非bufPtr）会让池失效
真正容易被忽略的是：缓冲区大小和读取模式必须匹配——顺序读日志用 64KB，二进制流控边界用 8KB，随机跳转才考虑 mmap；选错一个，其他优化全白搭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
