根本原因是未用bufio.reader包装或误用readall()：默认4kb缓冲导致频繁syscall卡顿，readall()加载全量数据致oom；应使用bufio.newreadersize(f, 64*1024)并循环调用reader.read()。
csv.Reader 读取大文件时卡住或内存暴涨
根本原因不是 csv.Reader 本身，而是你没给它套 bufio.Reader，或者用了 ReadAll()。默认的 csv.NewReader(io.Reader) 内部只用 4KB 缓冲，机械盘或 NFS 上频繁 syscall，看着就像“卡住”；而 ReadAll() 会把全部记录塞进 [][]string，GB 级文件直接 OOM。
实操建议：
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 用
bufio.NewReaderSize(f, 64*1024)包装*os.File，再传给csv.NewReader() - 绝对不用
ReadAll()；改用循环调reader.Read()，每行处理完立刻丢弃切片 - 缓冲区别设太小（invalid quoted field 错误
- 空行返回
[]string{}，不是 error，别 panic
字段数不固定、含嵌入换行或末尾逗号报错
典型错误是 record on line X: wrong number of fields 或 invalid quoted field。前者因默认校验每行字段数一致，后者多因引号未闭合或缓冲区太小导致解析中断。
实操建议：
- 设
reader.FieldsPerRecord = -1关闭字段数校验，后续靠业务逻辑判断有效性 - 确保源数据符合 RFC 4180：含换行/逗号/双引号的字段必须用双引号包裹，内部双引号写成
"" - 启用
reader.LazyQuotes = true可容忍部分非标准引号用法（如字段含引号但没包裹），但别依赖它修脏数据 - 检查 BOM：
file.ReadHeader()或手动读前 3 字节，遇到\uFEFF要跳过，否则首字段乱码
中文乱码、GBK 文件解析失败
encoding/csv 只认 UTF-8。源文件是 GBK、UTF-16 或带 BOM 的 UTF-8，都会导致字段错位、panic 或空字段。
实操建议：
- 先用
file.Header()检查前几个字节，识别编码（如0xFF 0xFE是 UTF-16 LE） - 非 UTF-8 文件，用
golang.org/x/text/encoding转码后再喂给csv.NewReader()，例如 GBK → UTF-8：
decoder := simplifiedchinese.GBK.NewDecoder() r := bufio.NewReader(file) utf8Reader := transform.NewReader(r, decoder.Transform) reader := csv.NewReader(utf8Reader)
reader.Comma = ';' 或 '\t'，别假设“CSV 就是逗号”写入时 Excel 打不开、列错位或最后几行丢失
常见于直接写 *os.File 给 csv.Writer，或忘了 Flush()。每调一次 Write() 就触发一次 syscall，性能差；不 flush 则缓冲区数据滞留内存，程序 panic 时就丢数据。
实操建议：
- 必须用
bufio.NewWriterSize(f, 1（1MB 缓冲）包一层，再传给 <code>csv.NewWriter() - 每写 1000 行或每次批量处理后，主动调
w.Flush()；别等defer w.Flush() - 写完务必检查
w.Error()，Write()和Flush()成功不代表磁盘写入成功（比如磁盘满） - 字段含特殊字符（逗号、换行、双引号）时，
csv.Writer会自动加引号并转义，但别用fmt.Fprintln拼接字符串——它绕过所有引号逻辑
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
