Go文件I/O性能优化关键在于按场景选择缓冲策略、同步时机和底层控制粒度：大文件顺序读用64KB缓冲，日志行读取用bufio.Scanner，高频小写入用8KB bufio.Writer并定期Flush，极致控制时降级syscall并手动处理错误重试，优先使用io.Copy替代手动循环，合理选用O_DSYNC而非O_SYNC，并结合磁盘类型与文件系统参数调优。
Go 的文件 I/O 默认行为在高吞吐或小文件高频场景下容易成为瓶颈，直接用 os.ReadFile 或逐字节 Read 会频繁触发系统调用、内存分配和锁竞争。关键不是“换函数”，而是根据场景选对缓冲策略、同步时机和底层控制粒度。
用 bufio.Reader / bufio.Writer 控制缓冲大小
默认 bufio.NewReader(os.Stdin) 使用 4KB 缓冲区，但实际业务中常需调整。小缓冲（如 512B）增加系统调用次数；过大（如 1MB）浪费内存且可能拖慢响应——尤其在多 goroutine 并发读同一文件时，缓冲区争用会抬高延迟。
实操建议：
- 顺序读大文件（>10MB）：设缓冲为
64 * 1024（64KB），平衡内存与 syscall 频次 - 日志行读取（每行较短）：用
bufio.Scanner并调ScanBytes()或设MaxScanTokenSize，避免单行超长导致 panic - 写入高频小数据（如 metrics 打点）：
bufio.NewWriterSize(f, 8*1024)，并定期Flush()，别依赖 defer
绕过 bufio 直接操作 syscall.Read 和 syscall.Write
当需要极致控制（例如实现零拷贝日志轮转、自定义页对齐写入），或处理 mmap 文件时，bufio 的额外封装反而引入冗余拷贝和错误转换开销。此时应降级到 syscall 层，但必须手动处理 errno、partial write、中断重试。
常见错误现象：调 syscall.Write(fd, buf) 返回 n 却未重试，导致数据截断。
实操建议：
- 始终检查返回值
n，循环写直到n == len(buf)或遇到不可恢复错误（如syscall.EBADF） - 读取时若
n == 0且err == nil，表示 EOF；若err == syscall.EINTR，需重试 - 避免在 hot path 中反复调
syscall.Open，复用已打开的intfd
for len(buf) > 0 {
n, err := syscall.Write(fd, buf)
if err != nil {
if err == syscall.EINTR {
continue
}
return err
}
buf = buf[n:]
}用 io.Copy 替代手动循环读写
很多人写 for { n, _ := r.Read(p); w.Write(p[:n]) }，这不仅逻辑冗余，还忽略 io.Copy 内置的优化：它会自动选择最优缓冲大小（基于 src/dst 是否实现 ReaderFrom 或 WriterTo），并在支持时直接调 sendfile 系统调用（Linux）或 CopyFileRange（>=5.3 kernel）。
使用场景：
- 文件复制、HTTP body 转存、pipe 管道桥接
- src 是
*os.File且 dst 是net.Conn时，io.Copy可能触发 zero-copy 路径 - 若需进度回调，用
io.CopyN分段或包装io.Reader实现计数
注意 os.O_SYNC 和 os.O_DSYNC 的真实开销
加 os.O_SYNC 看似“更安全”，但它强制数据 + 元数据（mtime/inode）落盘，SSD 上延迟可飙升 10–100 倍。多数场景只需确保数据持久化，用 os.O_DSYNC（仅数据落盘）更合理；若连数据都不强求立即落盘，就靠 f.Sync() 在关键点手动刷。
容易被忽略的地方：
-
os.Create默认不含同步标志，即使文件内容已写入，断电仍可能丢失 -
WriteString后不Flush()，缓冲区数据不会真正发出 - 在容器环境（如 Docker）中，宿主机 ext4 的
data=ordered模式会让O_DSYNC表现接近O_SYNC，需实测
文件 I/O 的性能拐点往往不在代码写法，而在你是否清楚当前磁盘类型（NVMe vs HDD）、文件系统
