应避免直接用 os.ReadFile 读取大文件，因其会一次性加载全部内容至内存导致 OOM 或阻塞；正确做法是用 os.Open + bufio.NewReader 实现流式处理。
大文件读取卡在 os.ReadFile？别用它
直接调用 os.ReadFile 读取几百 MB 甚至 GB 级文件，几乎必然 OOM 或长时间阻塞。它会一次性把整个文件加载进内存，且不提供进度控制或流式处理能力。
真实场景中，你真正需要的不是“读完”，而是“边读边处理”——比如解析日志、计算哈希、转码、分块上传。
替代方案：
• 用 os.Open 获取 *os.File，再套一层 bufio.NewReader 控制缓冲区大小（如 bufio.NewReaderSize(f, 1）<br>• 按需调用 <code>Read / ReadLine / ReadBytes，避免整文件驻留内存
• 若需逐行处理日志，优先用 scanner := bufio.NewScanner(file)，并设 scanner.Buffer(make([]byte, 4096), 1 防止超长行 panic
写入大文件时 os.WriteFile 慢得离谱？换 io.Copy + bufio.Writer
os.WriteFile 内部是先全量写入临时内存切片，再一次性 write(2) 系统调用，对大内容毫无优势。实测写 500MB 文件，比流式写慢 3–5 倍，且内存峰值翻倍。
更合理做法：
• 用 f, _ := os.Create("out.bin") 打开文件
• 包一层 w := bufio.NewWriterSize(f, 1（1MB 缓冲区通常够用）<br>• 用 <code>io.Copy(w, reader) 或循环 w.Write(p)，最后必须 w.Flush()
• 注意：若 writer 缓冲区太小（如默认 4KB），会导致 syscall 过多；太大（如 100MB）则失去流控意义，还可能延迟错误暴露
内存占用还是高？检查是否无意保留了 []byte 引用
Go 的 GC 不会主动归还内存给操作系统，尤其当大 []byte 被某个长期存活变量（如全局 map、未清空的 slice、闭包捕获）隐式引用时，内存会一直 hold 住。
常见陷阱：
• 把 scanner.Bytes() 直接存进 map 或 slice —— 它返回的是底层缓冲区的切片，一整块缓冲区都活不过 GC
• 用 strings.Split(string(b), "\n") 将大字节流转成字符串再切分 —— string(b) 不触发拷贝，但后续字符串切片仍共享原底层数组
解决办法：
• 需要保存某段内容时，显式拷贝：data := append([]byte(nil), b[start:end]...)
• 用 scanner.Text() 替代 scanner.Bytes()（它已做拷贝）
• 处理完一批数据后，手动置空局部 slice：buf = buf[:0]，帮助编译器识别可复用空间
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
并发处理大文件反而更慢？小心 I/O 瓶颈和锁竞争
对单个大文件做 goroutine 分段读（如 4 个 goroutine 各读 1/4），在机械硬盘或普通 SSD 上大概率比串行还慢 —— 磁盘寻道开销远大于 CPU 计算开销。只有在 NVMe + CPU 密集型处理（如解密、压缩）时才值得考虑并发。
若真要并发：
• 用 file.Seek(offset, io.SeekStart) 定位，但注意 *os.File 的 Read 方法不是并发安全的，需为每个 goroutine 单独 os.Open 同一文件（OS 层支持）
• 避免用 sync.Mutex 保护写入，改用带缓冲 channel 汇总结果，最后统一写盘
• 更推荐的并发模式：一个 goroutine 负责读（生产者），N 个 goroutine 负责处理（消费者），再一个 goroutine 负责写（消费者），用 channel 解耦，天然规避 I/O 争抢
立即学习“go语言免费学习笔记（深入）”；
最常被忽略的一点：性能瓶颈往往不在 Go 代码本身，而在你没关掉 fsync（比如用 os.O_SYNC）、没设对 ReadBuffer 大小、或者误以为“开了 goroutine 就等于加速”。先用 go tool pprof 看真实 CPU / alloc / IO 分布，再动手优化。
