gorp.Insert 传入的 []interface{} 必须是 *Struct 指针，直接 dbMap.Insert(users)（users 是 []User）会因 Go 类型系统限制编译失败；正确做法是预分配 []interface{} 并逐个赋值 &users[i]，否则运行时 panic。
gorp.Insert 传 []interface{} 必须是 *Struct 指针
直接 dbMap.Insert(users)（users 是 []User）会编译失败，错误是 cannot use users (type []User) as type []interface{}。这不是 gorp 的限制，而是 Go 类型系统强制要求：[]User 和 []interface{} 内存布局不同，无法隐式转换。
真正能被 dbMap.Insert 接收的，只能是 []interface{}，且每个元素必须是指向已注册结构体的指针（例如 *User）。否则运行时 panic：non-pointer passed to Insert 或 expected pointer to struct。
- 正确做法：预分配
args := make([]interface{}, len(users))，再用索引取地址：args[i] = &users[i] - 危险写法：在
for _, u := range users中写args[i] = &u—— 所有指针都指向同一个循环变量地址，数据全变成最后一项 - 更稳妥的初始化方式：直接构造
[]*User切片，避免中间取址环节
MySQL 批量插入别依赖 gorp，改用多值 INSERT + Prepare
gorp 的 Insert 本质仍是 N 次单条 INSERT（只是复用同一事务），对 MySQL 来说远不如原生 INSERT INTO t(col1,col2) VALUES (?,?),(?,?) 高效。尤其当单批超 100 行时，性能差距明显。
关键不是“要不要用 gorp”，而是“该场景下 gorp 是否合适”。微服务中高频、大批量写入（如日志归集、同步任务），应绕过 ORM，直连 *sql.DB：
立即学习“go语言免费学习笔记（深入）”；
- 每批控制在 100–500 行：避开
max_allowed_packet限制（MySQL 默认 4MB） - 先
db.Prepare一次，再stmt.Exec多组参数：避免 SQL 解析开销 - 占位符动态生成：用
strings.Repeat("(?, ?),", n)拼出 VALUES 子句，再把所有字段值平铺进[]interface{} - 字符串值必须经
mysql.Escape()转义（不是sql.EscapeString），否则存在注入风险
事务必须显式控制，不能靠 gorp 默认行为
gorp 的 Insert([]interface{}) 确实默认在单事务中执行，但这是“自动开启+自动提交”——对微服务不可控。一旦插入中途失败，你无法决定是回滚整批，还是跳过错误行继续；更严重的是，若调用链上游已开启事务，gorp 会新建嵌套事务，破坏一致性。
生产环境务必手动管理事务生命周期：
- 用
tx, err := dbMap.Begin()显式开启，失败立即返回，不执行后续逻辑 -
defer tx.Rollback()只是兜底，实际应在成功后显式tx.Commit() - 超大批量（如 > 5000 行）建议分段提交：每 500 行 commit 一次，防长事务锁表、主从延迟飙升
- 不要在 defer 中无条件 Rollback：若已 Commit，再 Rollback 会 panic
PostgreSQL 场景优先用 pgx.CopyFrom
如果微服务后端是 PostgreSQL，且数据源稳定（如内存切片、文件流），pgx.CopyFrom 是比任何 INSERT 都快的选择，实测快 5–10 倍。它不走 SQL 解析，直接二进制协议传输，绕过所有 ORM 层开销。
但硬性约束极强，稍错即失败：
- 必须用
*pgx.Conn，不能用*sql.DB或*gorm.DB - 字段顺序、类型必须与表结构严格一致：传
int给int64列会报cannot convert int to int64 - 数据需提前组织为
[][]interface{}（二维切片），不能边读边塞，否则内存爆炸 - CopyFrom 不触发触发器、不计算默认值，如有业务逻辑依赖这些，必须前置补全
最易被忽略的是错误定位——CopyFrom 出错只报 copy failed at row N，不会告诉你哪一列错。上线前必须做字段类型校验和空值预过滤。
