csv解析加速关键在i/o控制与错误韧性，而非盲目并发；需单goroutine顺序读取并处理bom、设fieldsperrecord=-1，transform阶段用goroutine池做cpu密集操作，load阶段批量插入并复用stmt。

goroutine 本身不是 CSV 解析加速器，盲目并发读或解析 CSV 反而容易崩——内存涨、连接满、字段错位、panic 频发。真正有效的并发设计，是把「可并行」和「必须串行」的部分切开，让每个环节各司其职。

别用 goroutine 并发读同一个 csv.Reader

csv.Reader 不是线程安全的，多个 goroutine 同时调用它的 Read() 方法会竞态，轻则 panic，重则数据错乱。更常见的是：你开了 10 个 goroutine 去读同一文件，结果全卡在系统调用上，实际吞吐还不如单协程。

• 正确做法：只用 1 个 goroutine 负责顺序读取（配合 bufio.NewReaderSize(f, 64*1024)），按行产出 record []string 或结构体，通过 channel 发给下游
• 必须手动跳 BOM：bytes.TrimPrefix(buf.Bytes(), []byte("\ufeff"))，否则首行解析失败
• 设 reader.FieldsPerRecord = -1，避免某行字段数波动导致整个 pipeline 中断

Transform 阶段才适合开 goroutine 池

解析后字段校验、类型转换（strconv.Atoi）、结构体映射、JSON 序列化等 CPU 密集操作，才是并发收益点。但要注意复用和错误隔离。

QuickBooks Mileage CSV

使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。

下载

• 启动固定数量 goroutine（如 runtime.NumCPU()），从 channel 消费原始行
• 每行转换前先 strings.TrimSpace，空字符串别直接传给 strconv，否则 panic
• 结构体字段用 csv:"name" tag + 预构建的 map[string]int 映射表，不硬编码下标
• 转换失败时记录完整上下文：line 12847, field "score": "N/A" → cannot convert to int

Load 阶段：批量插入比并发插入更关键

数据库才是并发导入中最脆的一环。100 个 goroutine 同时 db.Exec()，大概率触发 Error 1040: Too many connections 或 context deadline exceeded。

• Load 端只开 1–2 个 goroutine，负责接收转换后的结构体，攒够 5000–10000 条再批量提交
• 务必复用 stmt := db.Prepare("INSERT INTO t(...) VALUES(?, ?, ?)")，避免每次编译 SQL
• 别用 += 拼接参数切片，用 append() 并预估容量：make([]interface{}, 0, batchSize*3)
• 如果字段含空值，用 sql.NullString 等类型，别传 nil 或空字符串

生成 CSV 时也别并发写文件

多个 goroutine 往同一个 *os.File 写，不仅不会提速，还会因锁竞争和 buffer 冲突导致丢行、错位、panic。

• 生产者-消费者模型：多个 goroutine 并行生成记录（CPU-bound），写入一个带缓冲 channel（如 chan string，容量 1000）
• 单个 goroutine 作为消费者，从 channel 拉数据，调用 w.Write() + 定期 w.Flush()
• 写入前加 UTF-8 BOM：file.Write([]byte("\xEF\xBB\xBF"))，否则 Excel 打开中文乱码
• 字段含双引号？提前把 " 替换为 ""，csv.Writer 不自动转义

最常被忽略的点：**CSV 解析瓶颈从来不在 CPU，而在 I/O 控制与错误韧性**。你花半天调并发数，不如花十分钟把 bufio.NewReaderSize、BOM 处理、FieldsPerRecord = -1 和批量插入这几处写稳——后面加多少 goroutine，都只是锦上添花。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！