优先用 pgx.CopyFrom（PostgreSQL）或 LOAD DATA LOCAL INFILE（MySQL）批量插入万级数据，避免 db.Exec 循环；分批事务需动态设阈值，GORM.CreateInBatches 非银弹，预校验 CSV 数据必做。
直接用 db.Exec 循环插入万级数据，不是慢，是大概率失败——连接池耗尽、超时中断、WAL 写满、主从延迟飙升，这些都会在第 832 行或第 4917 行突然爆发。
PostgreSQL：优先用 pgx.CopyFrom，别碰 Exec 循环
它走的是 PostgreSQL 原生 COPY 协议，绕过 SQL 解析、单行绑定和事务开销，万条数据常压在 200ms 内。但硬性前提很具体：
- 必须用
pgx驱动（不是database/sql+ pq），且连接是*pgx.Conn - 字段顺序、类型必须和表结构完全一致：
int64不能传int，*string不能传string - 数据得提前转成
[][]interface{}，每行一维切片，不能边读 CSV 边塞 —— 否则内存扛不住 - 别在循环里反复调
CopyFrom；按 1000–5000 行/批分组，一批一调，避免连接协商开销累积
MySQL：拼多值 INSERT 是底线，LOAD DATA LOCAL INFILE 是上限
MySQL 没 COPY 协议，database/sql 又不支持参数化的多值 INSERT，所以你得手动拼 SQL，但安全边界必须守住：
- 单条语句最多插 1000 行，再大易触发
max_allowed_packet错误 - 字符串值必须用
mysql.Escape()（非sql.EscapeString）转义，fmt.Sprintf拼整条 SQL 是高危操作 - 如果能控制 MySQL 服务端配置，开启
local_infile=ON，并用go-sql-driver/mysql的allowLocalInfile=true参数，LOAD DATA LOCAL INFILE性能远超任何拼 SQL 方案 - 别信“预处理语句能解决一切”——
stmt.Exec循环仍是逐条 round-trip，只是省了 SQL 解析，没省事务和网络开销
通用分批事务：阈值比写法更关键
当数据库不支持 COPY（如 SQLite）或你被限制只能用标准 SQL，那就老实用事务分批，但“1000 行一批”这种建议毫无意义，真正要设的是三个动态阈值：
-
batchSize：从 100 起步，逐步加到 500；若字段含 TEXT 或索引 > 3 个，立刻回落到 200 -
context.WithTimeout：每个事务单独设超时（如 30 秒），别复用全局 context，否则一个慢批拖垮全部 - 重试条件：只对
driver.ErrBadConn、网络类错误（net.OpError）、context.DeadlineExceeded重试；主键冲突、类型错、NOT NULL 违反等业务错误必须记录后跳过
GORM 用户注意：CreateInBatches 不是银弹
它确实自动封装了事务和分批逻辑，但底层仍是 Exec 循环拼多值 INSERT，性能天花板明显：
- 对 PostgreSQL，比原生
pgx.CopyFrom慢 5–10 倍；对 MySQL，和手拼 SQL 差距不大 - 批次大小设为 1000 时，若某批中第 999 行报错，GORM 默认整批回滚，你无法拿到该行原始数据做降级处理
- 想保原子性又需细粒度错误定位？不如绕过 GORM，用
pgx或原生database/sql自己控事务 + 分批 + 行号绑定
最常被忽略的点：CSV 文件里的 BOM 头、换行符混用（\r\n 和 \n 并存）、时间字段为 nil 却用了非指针类型 —— 这些不会在编译时报错，而是在 CopyFrom 执行到第 3721 行时静默失败，错误信息只显示 “invalid input syntax”，没行号、没字段名。预校验和行号透传不是可选项，是上线前必做的动作。
