bufio.scanner按行读时缓冲区复用靠的是其内部固定大小的私有缓冲区，而非sync.pool；它在newscanner时预分配默认4kb缓冲，并在每次scan()后自动重用，无需手动get/put。
bufio.Scanner 按行读时，缓冲区复用靠的是什么？
靠的是它内部固定大小的私有缓冲区，不是 sync.Pool。你调用 bufio.NewScanner(file) 时，它已经悄悄预分配了一块默认 4KB 的缓冲，并在每次 scanner.Scan() 后自动重用这块内存——你不用管 Get/Put，也不该自己去动它。
常见错误是以为“没显式复用 = 没复用”，结果在循环里反复 make([]byte, 64*1024) 或往全局切片里 append(scanner.Text())，这反而让 GC 跟着跑、内存下不来。
- 必须在
scanner.Scan()前调scanner.Buffer(make([]byte, 64*1024), 10*1024*1024)：第一个参数是初始缓冲，第二个才是单行上限（防scanner: token too long） -
scanner.Text()返回的是拷贝，安全；scanner.Bytes()返回的是底层缓冲引用，若存进 map/slice 就等于锁住整块缓冲（比如 64KB），哪怕只取了前 10 字节 - 最后一行没换行符？
scanner.Scan()在 EOF 仍返回该行，无需额外判空——前提是没触发上面那个缓冲溢出
手动 bufio.NewReader 读二进制块，怎么复用缓冲才不拖慢？
直接在循环外声明一个固定大小的 buf，反复用 buf[:0] 截断重用。别碰 sync.Pool——对单个大文件顺序读，它的锁开销比一次 read(2) syscall 还高。
实测中，make([]byte, 64*1024) 在循环外声明，比从 sync.Pool 取同大小切片快 15%~20%，且 GC 压力更低。Go 1.22+ 对这种小切片的分配已高度优化。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 缓冲大小按场景选：
32KB–64KB适合日志类文本流；8KB–16KB更适合带协议头的二进制流（如 protobuf、自定义帧） - 读完后务必用
n, err := reader.Read(buf)，然后只处理buf[:n]，别直接拿整个buf去解析 - 写入慢设备（NFS、USB 盘）时，缓冲要放大到
1MB，否则 syscall 过多 + 等待叠加，吞吐暴跌甚至报broken pipe
sync.Pool 到底什么时候该用？
只在两种场景下值得引入：高频短生命周期 或 固定大块复用。对单个几百 MB 文件从头读到尾，sync.Pool 不仅没收益，还会因 Get/Put 的指针跳转和锁拖慢整体节奏。
它不是“缓冲区复用”的万能解，而是针对特定压力模式的工具。误用最典型的表现是压测吞吐不升反降，CPU 却卡在 runtime.futex 或 sync.(*Pool).Get 上。
- 适用场景一：每秒打开/关闭数百个小文件（如日志分片），每个需分配 1MB buffer → 用
sync.Pool避免 GC 抖动 - 适用场景二：单 goroutine 每秒调用上百次
Read，且每次读1MB固定块 → Pool 可减少 mmap 页分配延迟 - 定义池必须存指针：
return &b，使用时解引用：*bufPtr；Put 时传原指针，不能传buf或buf[:]，否则对象泄漏
为什么 mmap 在某些大文件场景反而更慢？
因为 mmap 不是“零拷贝”，它只是把文件映射进虚拟地址空间，真正访问时仍要触发 page fault、缺页中断、TLB miss。对顺序读几百 MB 日志，系统调用少但内存页管理开销上去了，整体未必更快；只有随机读、内存充足、且文件远大于可用 RAM 时，mmap 才有优势。
更关键的是：mmap 会把整个文件“逻辑上”占满进程虚拟内存，虽然物理内存按需加载，但某些监控工具或容器限制（如 cgroup memory.max）会把它当真实占用计数，导致误杀。
- 顺序读 >1GB 文本日志？优先用
bufio.NewReaderSize(f, 64*1024)+ 复用buf - 需要频繁跳转读某几段（如索引查 offset）？再考虑
mmap，并配syscall.MADV_RANDOM提示内核 - 别混用：mmap 后又用
os.File.Read，可能触发双重 I/O 或数据不一致
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
