必须用 os.open 配合流式接口而非 os.readfile，因后者强制全量加载易致 oom；文本优先 bufio.scanner（需显式扩容缓冲），二进制用 *os.file+read；io.copy 要调大缓冲至 1mb 并避免 sync.pool 复用。
别用 os.ReadFile，它根本不是流式接口
很多人一看到“读文件”就下意识写 os.ReadFile，结果 GB 级日志一进来直接 OOM，进程被系统 kill。这不是配置问题，是语义错配：os.ReadFile 的设计目标就是“小配置文件全量加载”，内部调用 io.ReadAll 强制 malloc 整块内存。真实业务里你几乎从不需要整份驻留——逐行过滤、帧解码、CSV 解析，都是边读边处理。
必须改用 os.Open 配合流式接口。打开后记得 defer file.Close()，否则 fd 泄漏比内存泄漏更快拖垮服务。
- 文本类（日志、JSON Lines）：优先用
bufio.Scanner，它自动分块、按需分配、不攒整文件 - 二进制或自定义格式（Protobuf 流、加密块、固定帧）：绕过 Scanner，用
*os.File+Read手动控节奏 - 需要跳过开头 N 字节或切固定大小块：用
io.LimitReader(r, chunkSize)，它返回新 reader，不移动原 offset，适合链式处理
bufio.Scanner 默认缓冲会爆掉，64KB 不是万能的
bufio.Scanner 看似省心，但默认单行上限 64KB 是个隐形炸弹。遇到含 base64 图片、超长 traceID 或未规范换行的日志，直接 panic 报 scanner: token too long。这不是 bug，是设计约束——它假设你处理的是“合理长度”的文本行。
必须显式扩容：
- 初始缓冲设大点：
scanner.Buffer(make([]byte, 64*1024), 10*1024*1024)，第二个参数是最大允许长度（10MB） - 若后续要字节操作（跳过 BOM、校验 CRC），用
scanner.Bytes()而非scanner.Text()，避免 string 转换开销 - 最后一行没换行符？
scanner.Scan()在 EOF 时仍会返回该行——前提是没触发上面那个缓冲溢出
io.Copy 不是银弹，慢盘上默认 32KB 缓冲会让吞吐暴跌
io.Copy 语义清晰、错误传播完整，确实是流式转发的首选。但它默认用 32KB 内部缓冲，在 NFS、Ceph、USB 盘或高延迟云盘上，syscall 过多 + 等待叠加，实测吞吐可跌 70% 甚至卡死报 write: broken pipe。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
关键不是换函数，而是调大缓冲并控制节奏：
- 对慢盘/HTTP 响应体，改用
io.CopyBuffer(dst, src, make([]byte, 1024*1024))（1MB 缓冲） - 别用
sync.Pool复用这个缓冲——压测反而更慢；直接每次 new 更稳 - 若上游不可控（如代理响应），加
time.AfterFunc监控单次Write超时，主动断连防僵死 - 写入目标时务必传
buf[:n]，而非整个buf，否则可能把上一轮残留脏数据一起写进去
手动 Read 分块时，io.ReadFull 是个坑
想“精确读 N 字节”就用 io.ReadFull？它在最后一块不足 N 字节时直接返回 io.ErrUnexpectedEOF，而这是正常结束信号，不是错误。业务逻辑被迫加一堆判断分支，还容易误判。
正确姿势是裸 Read + 显式 EOF 判断：
-
if n > 0 && err == io.EOF→ 最后一块，数据有效 -
if n == 0 && err == io.EOF→ 空文件或刚读完 - 每次只传
buf[:n]给处理函数，避免下游误用未初始化内存 - 块大小设在 32KB–1MB 之间：太小 syscall 过多；太大削弱流控，且在 USB/NFS 上反而卡住
真正难的从来不是“怎么读”，而是块边界与业务逻辑的对齐——比如断点续传要记 offset，加密流要对齐 cipher block size，这些地方缓冲区设置错了，后面全得重来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
