gorm的createinbatches不适用于微服务千万级批量写入，因其sql拼接易超限、错误处理隐蔽、无自动事务、钩子不按行触发且batchsize=1时性能退化。
Go微服务里批量写入千万级数据，为什么不能用GORM的CreateInBatches
因为微服务场景下，它既不满足性能要求，又掩盖关键错误。GORM的CreateInBatches底层仍是拼接INSERT INTO ... VALUES (),(),()，在MySQL中单语句超max_allowed_packet就直接失败；PostgreSQL则可能因参数数超限（65535）panic。更致命的是，它返回*gorm.DB而非error，你写if err := db.CreateInBatches(...)连编译都过不了——错误必须从result.Error里取，而很多团队直接忽略这个字段。
- 空切片安全，但传
nil或单个struct会panic -
batchSize设为1时退化成逐条插入，还多一层函数调用开销 - 事务需手动控制：
CreateInBatches不自动包裹在事务里，没db.Transaction兜底，每批都独立提交，QPS直接掉到个位数 - 钩子（Hooks）不按行触发，
BeforeCreate只跑一次，ID和时间戳不会自动回填到原结构体中
MySQL微服务批量导入，必须手拼VALUES但得防SQL注入
MySQL没有COPY协议，database/sql也不支持原生多值绑定，只能拼SQL——但拼错就是生产事故。核心矛盾在于：既要性能（单条INSERT带2000行），又要安全（不能用fmt.Sprintf硬拼字符串）。
- 数值类型必须用
strconv显式转字符串，比如strconv.FormatInt(id, 10)，避免int和int64混用导致格式错乱 - 字符串值必须用驱动提供的转义函数：
mysql.Escape()（go-sql-driver/mysql）或mssql.EscapeSQL()（go-mssqldb），不能靠strings.ReplaceAll - 单条语句控制在1000–2000行以内，超过容易触发
Packets larger than 'max_allowed_packet' - 别在循环里反复
db.Exec——每次都是新连接协商，应先拼好完整SQL，再一次性Exec
PostgreSQL微服务用pgx.CopyFrom，快5–10倍但类型必须严丝合缝
pgx.CopyFrom走二进制COPY协议，跳过SQL解析和参数绑定，是微服务高吞吐写入的首选。但它不像ORM那么宽容：类型错一位、顺序错一列、甚至int传int64都会报cannot convert int to int64，且错误只提示“copy failed at row N”，不告诉你哪列错。
- 数据必须提前组织成
[]interface{}二维切片，每行一维，列顺序与表字段严格一致 - 所有字段类型要匹配：数据库
bigint对应Go的int64，text对应string，timestamp对应time.Time - 别在for循环里反复调
CopyFrom——连接协商开销大，按1000–5000行/批分组，一批一调 - 事务仍需显式开启：
tx, _ := conn.Begin(ctx)，CopyFrom必须在事务内执行，否则无法回滚
微服务流式处理大数据，channel解耦拉取与处理比并发goroutine更重要
微服务资源有限，盲目起几百goroutine写DB只会压垮连接池或触发锁争用。真正卡点不是CPU，而是“拉取慢但处理更慢”导致内存堆积——比如DB查10万行，goroutine还没消费完，下一批又来了。
- 用固定worker数的管道模型：1个goroutine读DB（生产者），N个worker从
inCh chan *Record消费，1个goroutine聚合结果写库 -
inCh缓冲区设100–1000，太小易阻塞，太大吃内存；用close(inCh)通知worker结束，别靠ctx.Done()粗暴中断 - DB拉取必须用游标分页：
WHERE id > ? ORDER BY id LIMIT ?，禁用OFFSET——微服务长连接下，OFFSET超10万行后延迟从20ms涨到2s+ - 处理逻辑里避免阻塞操作：同步HTTP请求、无超时DB写入、未加锁的全局map更新，都会让整条流水线卡死
游标推进、类型对齐、事务边界、channel缓冲——这些不是“高级技巧”，而是微服务批量操作上线前必须对齐的四个硬性条件。漏掉任何一个，流量一上来就不是慢，而是不可用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
