应避免用os.readfile读大文件，因其一次性加载全部内容至内存易oom；正确做法是用os.open+bufio.newreader或scanner流式处理，按需分块或逐行读取并及时释放内存。
大文件读取别用 os.ReadFile
它会把整个文件一次性加载进内存，几百 MB 就可能触发 OOM，GB 级直接卡死或崩溃。真实场景要的不是“读完”，而是“边读边处理”——比如解析日志、计算校验和、转码、分块上传。
正确做法是：os.Open 获取 *os.File，再套一层 bufio.NewReader 或 bufio.Scanner：
- 逐行处理文本：用
bufio.Scanner，务必调scanner.Buffer(nil, 64*1024)设上限，防超长行 panic - 二进制或自定义分块：用
bufio.NewReaderSize(f, 32*1024)（32KB 缓冲区较均衡） - 避免
scanner.Bytes()直接存入 map/slice——它返回的是底层缓冲区切片，整块缓冲都活不过 GC；改用scanner.Text()或显式拷贝：data := append([]byte(nil), b[start:end])
写大文件别用 os.WriteFile
它内部先全量写入内存切片，再一次系统调用落盘，对大内容毫无优势。实测写 500MB 文件，比流式写慢 3–5 倍，内存峰值翻倍，且每次调用都 truncate + 重写，加剧文件系统逻辑碎片。
换成长生命周期的 *os.File + bufio.Writer：
- 打开文件：
f, _ := os.Create("out.bin")，复用这个f - 包装 writer：
w := bufio.NewWriterSize(f, 32*1024)（32KB 或 64KB 是推荐值，匹配页缓存） - 写入后必须调
w.Flush()；若需强一致性，再补f.Sync() - 避免高频
w.Reset(f)切换文件——sync.Pool复用bufio.Writer时，必须确保Reset后关联的是有效、未关闭的*os.File
分块上传必须带元数据与偏移控制
客户端只传块序号、文件 ID、当前 offset；服务端按 offset 写入临时文件，不拼接、不缓存整块内容到内存。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
关键点：
- 接收端用
io.Copy(w, r.Body)直接写磁盘，绕过中间[]byte分配 - 临时文件命名含文件 ID + 块序号（如
upload_abc123_part005），便于断点续传和清理 - 合并前校验每块 SHA256，防止网络损坏；合并用
cat part* > final或io.Copy循环读写 - 务必设置上传超时与单块大小上限（如 5MB/块），防恶意长连接或超大块耗尽内存
并发读写大文件反而更慢？先看磁盘类型
在 HDD 或普通 SATA SSD 上，并发分段读一个大文件（如 4 goroutine 各读 1/4）通常比串行还慢——磁盘寻道开销远大于 CPU 计算。只有在 NVMe + 多队列 + 随机访问密集型场景下，并发才有意义。
真正该并发的是“多个独立文件”或“生产者-消费者流水线”：
- 一个 goroutine 负责读块（生产），多个 worker 并发解密/校验/压缩（消费），用 channel 控制 buffer 数量
- 限制总并发数（如用
semaphore或带缓冲的 channel），防 fd 耗尽或 I/O 饱和 - 若真要分段读单个文件，用
file.Seek(offset, io.SeekStart)+io.ReadFull，但需预估并行度——NVMe 上建议 ≤8，SATA ≤2
最易被忽略的一点：Go 不会主动把大 []byte 占用的内存还给操作系统，哪怕变量已出作用域。只要某个长期存活对象（全局 map、未清空 slice、闭包捕获）隐式引用了它，那块内存就一直 hold 住。检查 pprof heap profile 里 top 的 []byte 分配源，比调优缓冲区更重要。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
