应避免用 csv.NewReader(file).ReadAll() 解析大 CSV 文件，因其将全部数据加载至内存导致爆炸式增长；推荐用 bufio.NewReaderSize 配合手动解析、FieldRef 偏移索引及流式处理以节省内存。
直接用 csv.NewReader(file).ReadAll() 解析千万行 CSV，内存炸掉不是 bug，是设计使然——每个 string 带 16 字节 header，5000 万字段光 header 就吃掉 800MB，再叠加上 []string 切片头、结构体对齐、底层数组冗余，1.5GB+ 完全合理。
别转 string，用 []byte + 偏移索引存字段
Go 字符串不可变且带独立 header，只要从原始 []byte 中切出一段并转成 string，就新增一个 16 字节 header；而所有字段若都来自同一块缓冲区，却各自持有一份 header，纯属浪费。
- 用
bufio.Scanner或自定义分割逻辑（如bytes.IndexByte手动找逗号）拿到每段起止位置，不调strings.Split，更不调strconv.Parse*前先转string - 定义轻量结构体，如
type FieldRef struct { data []byte; start, end int }，只存偏移，String()方法按需转（多数场景根本不需要） - 下游解析（如数值转换）直接用
strconv.ParseFloat(field.data[field.start:field.end], 64)，免分配 - 注意：该方式要求整块缓冲区生命周期覆盖全部字段访问，不能提前
gc掉；建议用bufio.NewReaderSize(f, 64*1024)控制单次读取粒度，避免过小 buffer 导致引号跨段解析失败
csv.Reader 必须套 bufio.Reader，且禁用 ReadAll
csv.NewReader 默认底层用 4KB 缓冲，对 GB 级文件 syscall 过于频繁，机械盘或 NFS 上明显卡顿；更严重的是，若某行含被双引号包裹的换行符，buffer 太小会导致引号断在两个 buffer 之间，解析直接失败。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 显式包装：
reader := csv.NewReader(bufio.NewReaderSize(file, 64*1024))，64KB 是多数场景平衡点 - 设
reader.FieldsPerRecord = -1，否则字段数波动（如备注列含逗号）会 panic - 手动跳 BOM：
buf := bufio.NewReader(file); _, _ = buf.Peek(3); if bytes.HasPrefix(buf.Bytes(), []byte("\xef\xbb\xbf")) { buf.Read(make([]byte, 3)) } - 绝对不用
ReadAll()——它把全部记录塞进[][]string，内存随行数线性暴涨
流式处理时，字段复用比结构体复用更重要
很多人花精力复用 struct 实例或预分配 []string 切片，但真正开销大头是每个字段的 string header 和底层字节拷贝。复用结构体只能省几十字节，而避免生成 5000 万个 string 能省掉 800MB+
立即学习“go语言免费学习笔记（深入）”；
- 不要为每行 new 一个结构体再填字段；改用固定长度 slice + 索引映射，例如
records[i%1024][colIdx] = FieldRef{...}循环复用缓冲区 - 如果必须转成结构体，字段类型优先选
[32]byte（固定长字符串）、int64、float64，而非string；短字符串可 memcpy 到栈上数组 - 写入下游（如数据库）时，也尽量传
FieldRef或[]byte，避免中间多一次string构造
最易被忽略的点：内存节省效果和你“何时丢弃原始 []byte 缓冲区”强相关。哪怕字段全用 FieldRef，只要缓冲区还活着，GC 就不敢回收——得确保业务逻辑处理完一行后，该缓冲区不再被任何 FieldRef 引用，否则优化全白做。
