Go 文件 I/O 不慢，但默认用法易致阻塞、内存爆炸或竞态；关键在选对 API 并控制缓冲边界：小文件用 os.ReadFile，大文件或需精度时用 io.ReadFull。
Go 的文件 I/O 本身不慢，但默认用法容易写出阻塞、内存爆炸或竞态的代码——关键在选对 API 和控制缓冲边界。
用 os.ReadFile 还是 io.ReadFull？看文件大小和精度要求
小文件（os.ReadFile 最简明；它内部已做合理缓冲，且返回 []byte 方便后续解析。但注意：它会一次性把整个文件读进内存，大文件会触发 GC 压力甚至 OOM。
需要精确读取固定字节数（比如解析二进制头）、或处理超大文件流式校验时，改用 io.ReadFull + os.Open：
file, _ := os.Open("data.bin")
defer file.Close()
var header [8]byte
_, err := io.ReadFull(file, header[:]) // 只读 8 字节，不越界
- 如果文件不足 8 字节，
err是io.ErrUnexpectedEOF，不是io.EOF -
io.ReadFull不自动重试，适合协议解析；而io.Read可能只读部分就返回，需手动循环 - 别用
bufio.NewReader(file).Read()替代——带缓冲的 reader 会预读，破坏“刚好读 N 字节”的语义
bufio.Scanner 默认 64KB 缓冲，大行日志会 panic
读文本行最常用 bufio.Scanner，但它默认最大单行长度是 65536 字节。遇到超长日志行或 JSON 行，会直接报 scanner: token too long 并停止扫描。
立即学习“go语言免费学习笔记（深入）”；
解决方法是显式调大缓冲区：
file, _ := os.Open("log.txt")
scanner := bufio.NewScanner(file)
buf := make([]byte, 1024*1024) // 1MB 缓冲
scanner.Buffer(buf, 1024*1024)
for scanner.Scan() {
line := scanner.Text() // 注意：Text() 返回的是 buf 的子切片，别跨 goroutine 用
}
-
scanner.Text()返回的字符串底层指向缓冲区，若需长期保存，必须string(append([]byte{}, scanner.Bytes()...))拷贝 - 如果行长度不可控，不如直接用
bufio.Reader.ReadString('\n')，它不限单行长度，但要自己处理io.EOF和\r\n -
Scanner不适合读二进制数据，换io.Read或binary.Read
写文件时 os.O_SYNC 和 fsync 别混用
确保数据落盘有两层：系统页缓存刷到磁盘（fsync），以及文件元数据更新（如修改时间）。Go 中常见误操作是开了 os.O_SYNC 还额外调 file.Sync()，这会重复刷盘，性能掉 3–5 倍。
- 只需数据可靠（如数据库 WAL）：开
os.O_SYNC，不用再Sync() - 既要数据又要元数据（如配置文件写完立刻可被其他进程 stat）：用
os.O_WRONLY | os.O_CREATE打开，写完后调一次file.Sync() - 临时文件写入后重命名（推荐模式）：先写到
tmp.XXX，file.Sync()后os.Rename()，避免部分写风险
并发写同一文件？先想清楚是不是真需要
多个 goroutine 直接写同一个 *os.File 是未定义行为——Write 不是原子操作，可能穿插字节、覆盖偏移。真正需要并发追加日志，应统一走 channel + 单 goroutine 写入；若必须多路并行，用 sync.Mutex 包裹 Write 调用，但性能瓶颈明显。
更轻量的替代是每个 goroutine 写独立临时文件，最后用 cat 或 Go 的 io.Copy 合并：
out, _ := os.Create("merged.log")
for _, f := range tempFiles {
file, _ := os.Open(f)
io.Copy(out, file) // Copy 内部用 32KB 缓冲，比逐 byte 快得多
file.Close()
}
缓冲区大小、是否启用 O_DIRECT、mmap 的适用场景——这些细节在真实高吞吐服务里才值得深挖，日常开发先守住上面四条，90% 的文件 I/O 问题就绕过去了。
