Go数据导入核心是保障稳定性，需避免逐条Exec插入，改用pgx.CopyFrom或LOAD DATA批量写入，并分批事务控制、统一CSV换行符、校验BOM、设超时与精准重试。
Go 语言做数据导入，核心不是“怎么写个循环插入”，而是“如何在不压垮数据库、不耗尽内存、不丢数据的前提下批量导入”。直接用 db.Exec 逐条 INSERT 是最常见也最危险的做法。
为什么 db.Exec 逐行插入在生产环境大概率会失败
这不是性能差的问题，而是稳定性问题：网络抖动一次、事务锁住几秒、连接池被占满，整个导入就卡死或报错。MySQL 的 max_allowed_packet、PostgreSQL 的 statement_timeout、甚至 Go 的 context.DeadlineExceeded 都会在你导入第 1287 条时突然抛出来。
- 每条
INSERT都是一次 round-trip，网络延迟放大 N 倍 - 默认
sql.DB连接池大小通常只有 2–10，高并发插入直接阻塞 - 没显式事务控制时，每条语句自动提交，IO 和 WAL 写入压力翻倍
- 出错时无法原子回滚——可能只插了前 3000 行，后 7000 行丢了也没提示
用 pgx.CopyFrom（PostgreSQL）或 mysql 的 LOAD DATA LOCAL INFILE 替代
这才是真正批量的底层能力，绕过 SQL 解析、单语句执行开销，直通存储引擎。PostgreSQL 用户优先选 pgx 的 CopyFrom；MySQL 用户注意：LOAD DATA LOCAL INFILE 需服务端开启 local_infile=ON，且客户端驱动（如 go-sql-driver/mysql）要加 allowLocalInfile=true 参数。
-
pgx.Conn.CopyFrom要求数据已加载到内存切片（[]interface{}），但可分批调用，每次传 5000–10000 行 - MySQL 的
LOAD DATA必须先写临时文件（/tmp/import_XXXX.csv），再执行 SQL，适合百万级以上导入 - 两者都不走普通
Exec路径，因此不会触发预处理语句限制或慢日志统计
示例（PostgreSQL）：
立即学习“go语言免费学习笔记（深入）”；
_, err := conn.CopyFrom(
ctx,
pgx.Identifier{"users"},
[]string{"id", "name", "email"},
pgx.CopyFromRows(dataRows), // dataRows 是 [][]interface{}
)
自己实现分批 + 事务控制时，必须设好三个阈值
如果数据库不支持 COPY 或你必须用标准 SQL（比如 SQLite 或某些云托管 MySQL 实例禁用了 LOCAL INFILE），那就老实用事务分批。但“分批”不是随便定 1000 行——得看字段长度、索引数量、事务日志容量。
-
批次大小：建议 100–500 行/批。超过 1000 行容易触发 MySQL 的
innodb_log_file_size溢出或 PostgreSQL 的max_wal_sizecheckpoint -
超时时间：每个事务设独立
context.WithTimeout(ctx, 30*time.Second)，别共用全局 context -
重试策略：仅对
driver.ErrBadConn、sql.ErrNoRows（少见）、网络类错误重试，**绝不重试唯一键冲突或约束错误**——那是数据问题，不是临时故障
CSV 文件解析阶段最容易忽略编码和换行符
Go 标准库 encoding/csv 默认按 \n 切行，但 Windows 生成的 CSV 常含 \r\n，更麻烦的是 Excel 导出的 CSV 可能带 BOM 和混合换行。一旦某行解析错位，后面所有字段全偏移，插入时类型报错（比如把字符串当 int64），但错误堆栈根本看不出是 CSV 问题。
- 读取前先用
bytes.HasPrefix(data[:min(3,len(data))], []byte{0xEF, 0xBB, 0xBF})检查 UTF-8 BOM 并跳过 - 用
strings.ReplaceAll(line, "\r\n", "\n")统一换行符，再喂给csv.NewReader - 务必启用
reader.FieldsPerRecord = -1，否则某行多一个逗号就直接 panic - 日志里打印出错行号 + 前 50 字符，比 “invalid syntax” 有用十倍
导入不是管道工活儿，它是个状态机：文件读取 → 类型转换 → 约束校验 → 数据库写入 → 错误归档。少盯任何一个环节，半夜告警的就是你。
