必须显式设64kb缓冲：默认4kb在nvme/千兆网络日志场景下仍高频触发read系统调用，64kb匹配ssd页大小与网络mtu，实测快2–5倍；超1mb易致l3 cache miss和goroutine阻塞。
Go 运行时完全不干预文件 I/O 调度，所谓“高性能”不是开 goroutine 就自动来，而是你得亲手控制缓冲大小、读写顺序、并发粒度和内存生命周期。
bufio.NewReaderSize 为什么必须显式设 64KB
默认 bufio.NewReader 用 4KB 缓冲，在 NVMe 或千兆网络日志场景下，仍会高频触发 read 系统调用——尤其当你用 ReadString('\n') 解析超长行时，实际吞吐卡在 syscall 切换上，而非磁盘带宽。
- 顺序读大文本（CSV/JSON/日志流）：固定用
bufio.NewReaderSize(f, 64*1024)，64KB 匹配多数 SSD 页大小与网络 MTU，实测比默认快 2–5 倍 - 别设 >1MB：L3 cache miss 显著上升，goroutine 可能被阻塞超过 10ms，反拖慢调度
- 绝对不要对同一个
*os.File套多个bufio.Reader：每个 Reader 独自维护底层文件偏移，必然跳字节或重复读
定长记录或大文件分段读，绕过 bufio 直接用 f.Read 和 f.ReadAt
当你要解析协议头、索引项这类严格定长二进制结构，bufio.Reader 的长度不确定性（Read 可能返回少于请求长度）反而引入额外判断和重试逻辑。
- 复用预分配的
[]byte：如buf := make([]byte, 0, 32)，循环调f.Read(buf)，避免ReadString或ReadLine的内存暴涨风险 - 大文件按字节范围分片处理：用
f.Seek(offset, 0)定位起始点，配合f.ReadAt(buf, offset)避免 Reader 内部偏移管理开销 -
ReadAt是线程安全的，同一文件多个 goroutine 并发读不同 offset 不需加锁，比 Seek+Read 更可控
io.CopyBuffer + sync.Pool 替代 io.Copy 降 GC
io.Copy 内部硬编码 32KB 临时切片，每次调用都执行 make([]byte, 32*1024)，高频小文件拷贝（如微服务间中转）会显著抬高 GC 压力，pprof 中常看到 runtime.mallocgc 占比超 30%。
- 定义全局缓冲池：
var bufPool = sync.Pool{New: func() interface{} { return make([]byte, 0, 64*1024) }} - 调用时传切片：
buf := bufPool.Get().([]byte); io.CopyBuffer(dst, src, buf[:0]); bufPool.Put(buf) - 注意：
io.CopyBuffer第三个参数必须是[]byte，传[64*1024]byte{}会导致每次 new 数组，更差 - 若
dst是 TLS 连接等不支持部分写的net.Conn，大缓冲可能触发多次Write，务必实测验证
并发读写单个文件时，worker 数量不是越多越好
盲目开 100 个 goroutine 并发读写一个文件，在机械盘或高负载服务器上，I/O 吞吐常断崖下跌——这不是并行，是争用。
- SSD 上通常 8–16 个 worker 足够；HDD 上 4–8 更稳；超了反而因寻道和调度开销拖慢整体
- 同一文件并发写入必须序列化：要么用
sync.Mutex，要么走 channel 排队，否则数据错乱不可逆 - 分段处理可分割大文件（如日志按时间戳切片）：每个 worker 处理固定字节范围，用
sync.WaitGroup协调，避免 seek 冲突 - 别在循环里反复
defer f.Close()：大量小文件场景下，close系统调用本身就有延迟累积，应显式 close 或用file.Close()+ 错误检查
最易被忽略的是缓冲区大小与并发数的组合效应——64KB 缓冲配 16 个 worker 在 NVMe 上跑得飞起，换到 HDD 上可能直接卡死。真实性能只在你自己的硬件 + workload 下跑出来，别信“通用最优值”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
