Go标准库encoding/csv需谨慎处理换行符、BOM、缓冲区和字段校验；统一换行符为\n、写入前加BOM、过滤控制字符可避免常见线上问题。
Go 标准库 encoding/csv 能可靠读写 CSV，但“能跑通”和“不出线上事故”之间差的不是语法，而是对换行符、BOM、缓冲区、字段校验这些细节的处理。
csv.Reader 读到一半就停住或卡死？先查换行符和 EOF 判断
常见现象是 ReadAll() 返回空切片、Read() 在最后一行反复返回 io.EOF 或阻塞不动。根本原因不是文件损坏，而是换行符不统一（\r\n、\r、\n 混用）或末尾缺换行，导致 csv.Reader 内部按 \n 切分时无法识别最后一行边界。
- 读取前用
bytes.ReplaceAll(data, []byte("\r\n"), []byte("\n"))和bytes.ReplaceAll(..., []byte("\r"), []byte("\n"))统一为\n - 别直接传
*os.File给csv.NewReader，套一层bufio.NewReader更鲁棒 -
err == io.EOF之后，必须检查record是否非空——空切片不等于没数据，可能是解析失败被跳过 - 如果源是 Excel 导出，优先怀疑
\r单独存在（尤其老版本），csv.Reader默认不处理它
中文在 Excel 里全显示问号？缺 BOM 是主因，不是编码错了
Go 的 string 天然是 UTF-8，encoding/csv 输出也是 UTF-8，但 Windows 记事本和 Excel 不靠编码声明，而靠文件开头的 BOM（\uFEFF）来识别 UTF-8。没这个三字节前缀，它们就当 ANSI 解码，中文必然乱码。
- 写入前手动调用
f.Write([]byte("\uFEFF"))，且必须是文件打开后、csv.NewWriter创建前的第一写操作 - 用
os.OpenFile(name, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0644)，避免os.Create的隐式截断干扰 BOM 位置 - BOM 只能出现在文件最开头；追加写（
O_APPEND）或中间插入都无效 - 如果目标系统是 Linux/macOS 终端或程序，BOM 反而可能引起解析异常，按需开关
csv.Writer.WriteString 报 “illegal utf8 sequence”？其实是控制字符惹的祸
这个错误信息极具误导性。它不是说字符串不是合法 UTF-8（比如含 \xFF），而是 csv.Writer 内部调用了 utf8.Valid 后又额外拒绝了某些控制字符（如 \x00、\x01、\x0B 等），因为多数 CSV 解析器根本不接受二进制零字节或不可见控制符。
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
立即学习“go语言免费学习笔记（深入）”；
- 预处理字段：用
strings.Map(func(r rune) rune { if r >= 0 && r = 14 && r 清掉常见控制符 - 别依赖
fmt.Sprintf拼接字段——C 接口或二进制解析来的数据常带隐藏\x00 - 写入前双重校验：
utf8.ValidString(s)+strings.ContainsAny(s, "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x0B\x0C\x0E\x0F\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1A\x1B\x1C\x1D\x1E\x1F") - 错误类型是
*csv.ParseError，可从中拿到Line和Column定位具体哪一行哪一列出问题
大 CSV 文件一 ReadAll 就 OOM？必须流式读 + 显式释放引用
csv.NewReader.ReadAll() 会把整张表加载进内存，10 万行 × 10 列的 CSV 轻松吃掉 200MB+。Golang 不会自动 GC 中间切片，尤其字段含长文本时，内存只增不减。
- 改用
for record, err := r.Read(); err != io.EOF; record, err = r.Read()循环逐行处理 - 每行处理完立刻
record = nil，避免闭包或 goroutine 持有对原始切片的引用 - 如果要把某行传给 goroutine，用
append([]string(nil), record...)做深拷贝，否则所有 goroutine 共享同一底层数组 -
Reader.FieldsPerRecord设为 -1 可禁用字段数校验，但代价是后续逻辑必须自己处理不齐整的数据
最常被忽略的点是：BOM 必须在第一字节、Flush() 必须调用、控制字符必须预清理——这三件事不做，哪怕语法完全正确，也会在线上环境突然失效。
