csv.NewReader 默认吃内存，ReadAll() 必须禁用——500 万行 × 10 列 CSV 仅 string header 就占 800MB；应改用 bufio.NewReaderSize(64KB)、手动跳 BOM、设 FieldsPerRecord=-1，并用 bytes.IndexByte 定位字段偏移，延迟 string 转换，数值解析直传 []byte，写入时配缓冲并主动 Flush。
csv.NewReader 默认吃内存，ReadAll() 必须禁用——500 万行 × 10 列 CSV，光 string 头就吃掉 800MB，这不是 bug，是 Go 字符串结构决定的硬开销。
为什么不能用 csv.NewReader(f).ReadAll()
它会把全部字段转成 []string，每字段 16 字节 header（指针 + 长度）+ 底层字节拷贝。5000 万个字段 ≈ 800MB 仅 header 开销；再加原始数据、[][]string slice 头、结构体对齐，1.5GB+ 是合理下限。ReadAll() 还让 GC 压力陡增，缓存局部性差，哪怕你只取第 2 列，它仍为整行 10 个字段全分配 string。
必须配 bufio.NewReaderSize 且设 64KB 缓冲
默认 bufio.Reader 缓冲区仅 4KB，小缓冲 + 引号跨 buffer 就导致解析失败（不是数据问题，是读取姿势不对）。尤其当某列含换行符且被双引号包裹时，buffer 太小会让引号断在两个 buffer 之间，csv.Reader 直接 panic。
reader := csv.NewReader(bufio.NewReaderSize(f, 64*1024))- 手动跳过 BOM：
if bytes.HasPrefix(data[:min(3, len(data))], []byte{0xEF, 0xBB, 0xBF}) { data = data[3:] } - 字段数不固定时，设
reader.FieldsPerRecord = -1，否则某行多逗号就报record on line X: wrong number of fields
绕过标准库字段转 string 的逻辑
所有优化的前提，是彻底避开 csv.Reader.Read() 内部为每个字段 new string 的行为。别用 strings.Split，别调 strconv.ParseFloat(line[i]) 前先转 string。
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 用
bytes.IndexByte手动找逗号，记录[start, end]偏移而非切出string - 定义轻量结构体：
type Row { Key [22]byte Offsets [10][2]int }，500 万行元数据仅 ~270MB - 真正需要字符串时再调
string(data[r.Offsets[i][0]:r.Offsets[i][1]])——Go 1.22+ 对这种切片已优化为零分配 - 数值转换直接用
strconv.ParseFloat(data[start:end], 64)，免中间string构造
写入也得流式 + 缓冲 + 主动 Flush()
直接传 *os.File 给 csv.NewWriter() 等于裸 syscall，GB 文件可能慢几倍；不配缓冲，BOM、换行符、引号嵌套全会出错。
立即学习“go语言免费学习笔记（深入）”；
w := csv.NewWriter(bufio.NewWriterSize(f, 1024*1024))- 每写完 1000 行调一次
w.Flush()，别等 defer 或程序退出——万一 panic 就丢数据 - 分流写多个文件时，为每个目标文件维护独立
csv.Writer+bufio.Writer，别反复os.Create() - 导出 HTTP 下载时，
w.UseCRLF = true兼容 Excel，且响应头必须在写入前设置
[][]byte，但如果底层还调 csv.Reader.Read() 或 strings.Split，就白忙——所有这些优化的前提，是彻底绕过标准库字段转 string 的逻辑。 
