gorm 本身不提供 cdc 能力，必须通过独立 cdc 组件（如 canal、debezium 或 pglogrepl）监听数据库 binlog/逻辑复制日志来实现变更捕获，而非在 gorm hook 中发 kafka 消息，以避免事务不一致、写入失败、覆盖不全及性能瓶颈等问题。
GORM 本身不提供 CDC 能力，它只是 ORM 层；想用 GORM + Kafka 做变更捕获，必须在业务写入路径外另起监听机制——不能靠 GORM 的 Save 或 Update 自动发消息。
为什么不能在 GORM Hook 里直接发 Kafka 消息
常见误区是给 BeforeSave 或 AfterUpdate 钩子加 Kafka 生产逻辑。这看似简单，但会引入严重问题：
- 事务未提交前就发消息 → Kafka 消费端可能读到“已变更”但数据库回滚了的数据
- 钩子执行失败（如网络抖动、Kafka 不可用）会导致整个数据库写入失败，违背“写库优先”原则
- 无法覆盖 DDL 变更（如新增字段）、非 GORM 写入（如 DBA 直连 SQL、其他服务写入）
- 高并发下生产者阻塞会拖慢 API 响应，
GORM的链式调用变成串行瓶颈
正确做法：GORM 写库 + 独立 CDC 组件监听 Binlog
以 MySQL 为例，GORM 负责干净地写库，CDC 由 Canal 或 Debezium 承担，Kafka 是中间通道。GORM 完全不感知变更事件流：
-
GORM正常执行db.Transaction，确保数据一致性；成功后立即返回 HTTP 响应 - Canal 连接 MySQL 的 binlog，解析
UPDATE user SET name=? WHERE id=?类型事件，推送到 Kafka Topic（如mysql.user） - Go 消费者用
github.com/segmentio/kafka-go订阅该 Topic，收到消息后做缓存刷新、搜索同步等下游动作 - 若需关联 GORM 模型逻辑（如根据
user.id查出完整结构体），消费者中再调用db.First(&u, msg.Value)，而非在写入时硬耦合
PostgreSQL 场景下用 pglogrepl 替代 Canal
如果你用的是 PostgreSQL，别走 Canal 路线。pglogrepl 是 Go 原生方案，轻量且可控：
- 必须提前配置 PostgreSQL：
wal_level = logical、max_replication_slots >= 1、创建专用复制角色（CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'xxx'） - 启动时调用
pglogrepl.CreateReplicationSlot，否则重启后丢失历史变更 - 消息里含完整
before/after行数据和txid，比 JSON 解析更可靠；无需 Schema Registry，也不依赖 Kafka Connect - 注意：pglogrepl 不处理 DDL，只捕获 DML；若需表结构变更通知，得额外监听
pg_event_trigger
消费者端反序列化 Debezium JSON 消息的坑
Debezium 输出的 JSON 不是扁平结构，直接 json.Unmarshal 到自定义 struct 会丢字段或 panic：
- 真实数据藏在
payload.after字段里，不是顶层after - 必须先解出
map[string]interface{}，再取payload，再取after，最后转成你的User结构体 - 字段名大小写敏感：
payload小写，after小写，但表字段如user_name在 JSON 中仍是下划线风格，GORM 标签要匹配（gorm:"column:user_name"） - 时间字段默认是字符串（如
"2026-08-19T08:05:12Z"），别用int64接；用time.Time并注册自定义UnmarshalJSON
最易被忽略的一点：Kafka 消费位点管理。用 kafka-go 时，CommitMessages 必须在业务逻辑成功后显式调用，否则重复消费会导致缓存双删、索引重复写入。这不是 GORM 能兜底的事，得在消费者代码里死守这个顺序。
