优先用 bufio.NewReaderSize(file, 8*1024)（8KB），避免设为1MB以上；改用 ReadLine() 替代 ReadString()；禁用 mmap，可用 syscall.Readahead 预读；单通道介质宜串行读，避免并发争抢。
只读介质上 bufio.NewReaderSize 缓冲区大小怎么设才不浪费
只读存储介质（如 CD-ROM、只读 NFS 挂载点、嵌入式只读 flash）通常带宽低、延迟高、无写缓存，盲目加大缓冲区反而会拖慢首次响应——因为预读数据可能远超实际需要，且无法被内核缓存复用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 优先用
bufio.NewReaderSize(file, 8*1024)（8KB），比默认 4KB 更适配大多数只读介质的块大小 - 避免设成 1MB 或更大：大缓冲会触发一次长耗时预读，而后续行处理若只用前几 KB，剩余数据就白读了
- 若已知文件结构（如固定每行 128 字节的日志），可按倍数设为
1024或2048，减少内部切片扩容 - 不要复用同一个
bufio.Reader实例跨多个文件——不同介质的预读行为差异大，容易导致缓冲错位
ReadString('\n') 在只读介质上为什么经常卡住
因为 ReadString 内部依赖底层 Read 填满缓冲区，而只读介质在遇到坏扇区或 ECC 校验重试时，单次系统调用可能阻塞数百毫秒。此时 ReadString 会等满整个缓冲区才返回，而不是“有换行就交”，造成假性卡顿。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 改用
reader.ReadLine()：它只读到换行符为止，不等待缓冲区填满，响应更快 - 对关键路径加超时控制：用
file.SetReadDeadline（注意仅对支持的文件描述符有效，如普通文件；NFS/CIFS 可能忽略） - 若必须用
ReadString，先file.Stat()看文件大小，预估最大行长，再设缓冲区略大于该值，避免反复填不满
mmap 在只读介质上是否真有用
基本没用，甚至有害。mmap 依赖页错误触发按需加载，但在只读介质上，一次页错误可能引发整页（4KB）的物理读取+校验+重试，而顺序读用 bufio 可以合并相邻访问、跳过已知坏区（如果驱动支持）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 禁用 mmap：第三方库如
github.com/edsrzf/mmap-go在只读介质上常返回ENODEV或EROFS，别硬试 - 真正有效的替代是预读提示：Linux 下可调用
syscall.Readahead（需unix包），提前触发介质底层预加载，但效果取决于驱动实现 - 更稳的做法是：用固定块（如 64KB）循环
file.Read(buf)，配合io.Discard跳过不需要的部分，避免 mmap 的虚拟内存管理开销
并发读多个只读文件反而更慢？
是的，尤其在单通道只读介质（如 USB 2.0 光驱、老旧 SATA IDE 模式）上，多个 goroutine 并发读会引发磁头/寻道争抢，实际吞吐可能低于串行。Go runtime 的调度无法感知底层 I/O 队列深度，goroutine 切换反而增加上下文开销。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 强制串行：用单个 goroutine 按顺序读取，省去锁和 channel 协调成本
- 若必须并发（如多光盘托架），每个介质独占一个 goroutine，且用
sem := make(chan struct{}, 1)限制每介质最多 1 个 reader - 避免
os.ReadFile：它内部用bytes.Buffer动态扩容，在只读介质慢速响应下会反复 realloc，比预分配[]byte多出 2~3 倍内存拷贝
file.Read 返回的 n 是否等于 len(buf)，在只读介质上比在 SSD 上更值得检查。 
