Go无法直接集成Debezium，只能作为Kafka消费者解析其输出的变更事件；需用franz-go等库处理Avro Schema、NULL字段和事务性重复/乱序问题。
Go 里没法直接用 Debezium
Debezium 是 JVM 生态的 CDC 工具，核心是 Kafka Connect 插件，它本身不提供 Go 客户端 SDK。你在 Go 项目里写 DebeziumClient 或调 startDebeziumConnector() —— 这些都不存在。
真实可行路径只有一条：Go 作为下游消费者，从 Kafka 拉取 Debezium 输出的变更事件。别想绕过 Kafka Connect 去“集成 Debezium”，那是方向性错误。
- Debezium 负责监听数据库 binlog / wal，序列化成
JSON或Avro发到 Kafka Topic（如server1.inventory.customers） - Go 程序只需用 Kafka 消费者（比如
sarama或franz-go）读这些消息，再解析 payload - 如果你试图在 Go 里“启动 Debezium”或“配置 MySQL connector”，说明你混淆了部署角色：那是运维/Java 工程师配 Kafka Connect 集群的事
解析 Debezium JSON 消息时字段嵌套容易崩
Debezium 输出的每条消息 value 是多层嵌套 JSON，最外层是 before/after/source/op 等字段，after 里才是业务数据——但它的结构取决于数据库 schema 是否含 NULL、是否启用了 include_schema 等配置。
直接 json.Unmarshal 到 struct 容易 panic，尤其当某列值为 NULL 但 struct 字段没声明为指针或 sql.NullString 类型时。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐先用
map[string]interface{}解一层，检查op字段是否为c（create）、u（update）等，再决定取after还是before -
source.ts_ms是变更时间戳，类型是 int64，不是字符串；source.table才是表名，别错当成topic名 - 如果 Debezium 配了
"transforms": "unwrap"（使用ExtractNewRecordState），则顶层字段会扁平化，after消失，直接是业务字段——这点必须和 Kafka Connect 配置对齐，否则解析逻辑全错
用 franz-go 比 sarama 更省心处理 Avro Schema
如果 Debezium 输出的是 Avro（常见于生产环境），而你又不想自己搭 Schema Registry client，franz-go 内置了 franz-go/pkg/sr 模块，能自动拉取并缓存 Schema，配合 franz-go/pkg/kgo 消费时自动反序列化。
sarama 完全不碰 Schema，你得手动集成 gaussian13/goavro 或 hamba/avro，还要处理 Schema ID 的提取、Registry 认证、缓存失效等问题。
- 确保 Kafka 消息 header 含
schema-id（Debezium 默认开启），franz-go才能自动识别 - 初始化
sr.Client时传入 Registry 地址，如"http://localhost:8081"，别漏掉协议头 - 消费循环里用
record.Value.Decode(...)，它内部会查 Schema 并转成map[string]interface{}或自定义 struct（需提前注册）
事务性变更（snapshot + binlog）导致重复或乱序
Debezium 切换 snapshot 和 streaming 阶段时，可能发出两条内容相同但 source.snapshot 值不同的消息（true → false），或同一行在 snapshot 中发一次、binlog 中又发一次。Go 消费端若不做去重，业务侧就会看到重复更新。
更麻烦的是，Kafka 分区只能保证单分区有序，而 Debezium 默认按表名哈希分发，跨表更新就天然无序——比如订单表更新后立刻发物流表更新，消费者可能先收到物流再收到订单。
- 用
source.lsn（PostgreSQL）或source.file+source.pos（MySQL）做幂等判断，比用业务主键更可靠 - 不要依赖消息到达顺序实现强一致性逻辑；需要严格时序的场景（如账户余额），应在 Go 侧加内存队列或用
group by table_name分多个 consumer 实例 - 首次启动消费前，确认
auto.offset.reset设为earliest，否则错过 snapshot 阶段消息
真正卡住人的从来不是“怎么连 Kafka”，而是 schema 变更后 Avro 解析失败、NULL 字段炸掉 Unmarshal、或者以为消息有序结果业务逻辑跑飞——这些细节不贴着日志和实际 payload 看，光读文档根本避不开。
