应手动分块读取大文件以避免内存溢出，固定分配复用缓冲区，始终检查 reader.Read 返回值 n 和错误，按行处理时需限制 scanner.Buffer 大小。
用 os.Open + bufio.Reader 控制单次读取大小
直接 os.ReadFile 或 ioutil.ReadAll 会把整个文件加载进内存，1GB 文件就可能吃光可用堆空间。必须手动分块，核心是控制每次调用 Read 的缓冲区大小，而不是依赖默认行为。
常见错误是只调用 reader.Read(buf) 却不检查返回值 n，导致后续逻辑误以为读满整个 buf；或者用 scanner.Scan() 处理超长行时触发内部扩容，悄悄耗尽内存。
- 固定分配一个
buf := make([]byte, 4*1024*1024)（如 4MB），复用避免频繁 GC - 始终用
n, err := reader.Read(buf)，只处理buf[:n]区间 - 遇到
io.EOF时停止，不要忽略err == nil以外的错误（比如磁盘 I/O 中断） - 若需按行处理且行长度不可控，改用
bufio.Scanner并设置scanner.Buffer(make([]byte, 64*1024), 1 限制最大行长
用 io.CopyN 或 io.LimitReader 按需截断流
当只需处理文件前 N 字节（如解析头部元信息、校验 checksum），或要将大文件切片上传时，硬编码循环读取既啰嗦又易错。Go 标准库提供了更语义清晰的流控制方式。
io.CopyN(dst, src, n) 会精确复制 n 字节并返回实际字节数；io.LimitReader(r, n) 则包装原 io.Reader，后续所有读操作在累计 n 字节后自动返回 io.EOF。两者都避免手动计数和边界判断。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 解析 PNG 头部只需前 8 字节：
io.ReadFull(limitedReader, headerBuf) - 上传分片时，对每个分片创建
io.LimitReader(file, partSize)，再传给 HTTP client - 注意
io.CopyN在src提前 EOF 时会返回io.ErrUnexpectedEOF，需区分处理 - 不要对同一底层文件多次调用
io.LimitReader而不重置file.Seek(0, 0)，否则位置偏移会导致跳过数据
用 mmap（golang.org/x/sys/unix.Mmap）绕过 Go runtime 内存管理
当文件极大（几十 GB）、且需随机访问（如查找特定 offset 的记录）或反复扫描时，传统分块读取仍可能因频繁系统调用和内核/用户态拷贝拖慢速度。此时可考虑内存映射——让 OS 将文件页按需载入物理内存，Go 程序直接操作指针。
标准库不提供跨平台 mmap，需借助 golang.org/x/sys/unix（Linux/macOS）或 golang.org/x/sys/windows（Windows）。关键风险在于：映射区域被 GC 回收后指针失效，或未显式 Munmap 导致资源泄漏。
- 仅限可信、只读场景使用；写入需额外同步逻辑
- 映射后得到
[]byte切片，但底层内存不由 Go GC 管理，必须手动unix.Munmap - 用
runtime.KeepAlive防止切片被过早回收（尤其在 long-running goroutine 中） - 小文件没必要 mmap，系统调用开销反而更高；建议 >100MB 且访问模式复杂时再评估
处理并发分块时的文件偏移与状态同步
多个 goroutine 同时读同一文件的不同区间（如并行哈希计算、日志分析），不能简单共享一个 *os.File 并发调用 Read——Read 会修改文件内部 offset，结果不可预测。必须显式控制每个 goroutine 的起始位置。
正确做法是每个 goroutine 拿到独立的 *os.File 句柄（os.Open 新打开），或用 file.Seek(offset, 0) 定位后再读。后者要注意竞态：若其他 goroutine 同时调用 Seek，offset 会被覆盖。
- 推荐为每块分配独立
*os.File，用defer f.Close()确保释放 - 若复用句柄，必须加
sync.Mutex保护Seek+Read组合操作 - 计算块边界时，避免整除截断导致最后一块漏掉：用
start := int64(i) * chunkSize，end := min(start+chunkSize, fileSize) - 用
atomic.Value或 channel 传递处理进度，别用全局变量+锁，易引发死锁
真正难的不是分块本身，而是搞清数据边界在哪——文本编码可能跨块断裂，压缩流需要连续上下文，加密块要求严格对齐。这些地方没处理好，分块反而引入新 bug。
