Go处理超大CSV文件内存爆掉的主因是默认行为未覆盖：ReadAll()全载入内存、4KB缓冲易解析失败、WriteAll()积压数据；应改用Read()流式处理、64KB bufio缓冲、ReuseRecord复用切片、手动处理BOM/空行/编码等边界。
Go 处理超大 CSV 文件时内存爆掉，基本不是代码写错了，而是默认行为没被覆盖——csv.NewReader 不缓存整文件，但你若直接传 *os.File 给它，底层用的是 4KB 缓冲；ReadAll() 更是直接把全部记录塞进 [][]string，字段多、行数多、字符串长，内存几秒就飙到几十 GB。
别用 ReadAll()，改用 Read() 循环流式处理
这是最常踩的坑：一行 records, _ := csv.NewReader(f).ReadAll() 看似干净，实则把整个文件结构化后全留在堆上。GC 来不及回收，[][]string 的嵌套切片还会放大内存开销。
- 必须改成
for { record, err := reader.Read() }模式，每行处理完立刻丢弃引用（别 append 到大 slice 里） -
reader.ReuseRecord = true可复用底层缓冲，避免每行都 new 新切片（注意：record 是复用的，要拷贝才安全） - 如果后续要存进 map 或发到 channel，
append([]string(nil), record...)显式拷贝，否则下一行Read()会覆盖前值
给 csv.Reader 套 bufio.NewReaderSize，缓冲区设为 64KB
直接传 *os.File 给 csv.NewReader，底层 syscall 频繁，尤其在机械盘或 NFS 上卡顿明显；更危险的是，若某行含被引号包裹的换行符（合法 CSV），4KB 缓冲容易让引号跨 buffer，导致解析失败。
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 显式封装：
reader := csv.NewReader(bufio.NewReaderSize(f, 64*1024)) - 64KB 是多数场景的甜点值：太大拖慢 GC，太小引发 syscall 和解析断裂
- 别用
bufio.Scanner替代——它按行切分，不理解 CSV 引号规则，遇到"a,b\n c"这种直接断成两行
写入大 CSV 时禁用 WriteAll()，手动配 bufio.Writer + 定期 Flush()
csv.Writer.WriteAll() 内部仍是循环 Write()，但你不控频，OS 缓冲区可能积压几 MB 才落盘；更糟的是，它仍会先把所有数据转成 [][]string，和 ReadAll() 是同一类陷阱。
- 正确姿势：
w := csv.NewWriter(bufio.NewWriterSize(outFile, 1024*1024))（1MB 缓冲） - 每写 1000–10000 行调一次
w.Flush()，避免积压；每次Flush()后检查w.Error()，尤其写 HTTP response 或 pipe 时 - 别依赖
defer w.Flush()收尾——万一 panic，最后一批数据就丢了
字段数不固定、BOM、空行这些“现实数据”得手动兜底
RFC 4180 是理想标准，真实 CSV 充斥着 Windows 记事本导出的 BOM、末尾逗号、空行、字段内换行、中文乱码……encoding/csv 一概不管，全靠你显式补位。
- BOM 必须手动 trim：
bytes.TrimPrefix(buf.Bytes(), []byte("\ufeff"))，否则第一行字段名带 \uFEFF - 设
reader.FieldsPerRecord = -1关闭字段数校验，否则某行少个字段就panic: wrong number of fields - 空行返回
[]string{}，不是 error，别当成异常中断流 - 中文乱码？先确认源文件是 UTF-8；GBK/Big5 要用
golang.org/x/text/encoding转码后再喂给csv.Reader
真正难的不是写对一行代码，而是在每一处「默认行为」旁贴上手写的控制逻辑：缓冲大小、BOM 处理、字段校验开关、Flush 频率、编码转换——CSV 库只管分隔符和引号，其余全是你的责任边界。
