GORM事务无法覆盖ES操作，需显式处理ES写入结果并做补偿；应使用钩子而非Save()双写，避免结构不一致和性能损耗；软删除需特殊处理以防ES残留脏数据。
同步双写时，GORM事务无法自动包裹ES操作
GORM的@Transactional或db.Transaction()只对MySQL生效，ES客户端调用完全游离在事务边界之外。哪怕你把esClient.Index()写在GORM事务块里，MySQL提交成功后ES失败，事务也不会回滚——这不是GORM的缺陷，而是跨存储事务天然不支持。
常见错误现象：panic: ES write failed没被catch，或者catch了但只打日志、没做补偿，导致MySQL有数据、ES查不到；更隐蔽的是ES写入超时被GORM忽略，MySQL已落库，ES实际未送达。
- 必须显式处理ES写入结果：检查
response.IsAcknowledged()（Go es client）或response.StatusCode == 201（HTTP client） - 失败时不能简单抛异常：金融类场景需触发本地事务表记录待重试项；普通业务可用
defer启动异步重试goroutine，但要加幂等key（如order_id:updated_at） - 避免在GORM事务内直接调用阻塞型ES HTTP请求：网络抖动会拖长MySQL锁持有时间，建议用带超时的
context.WithTimeout(ctx, 800*time.Millisecond)
用GORM钩子（Hooks）做双写，比硬编码更可控
GORM的AfterCreate、AfterUpdate等钩子函数，在事务提交后立即触发，语义上比手动插在业务逻辑里更清晰。但它仍不是事务的一部分，只是“刚好在commit之后执行”。
使用场景：订单、商品、用户资料等变更频率中等（
- 钩子里必须用独立DB连接查最新数据：GORM钩子传入的
tx可能已被回收，直接读tx.First()易panic，应新建db.WithContext(ctx).First() - ES文档ID建议复用MySQL主键：
document_id => "%{id}"，避免生成UUID导致关联查询困难 - 删除操作别漏掉
AfterDelete钩子：否则ES残留脏数据，搜索会返回已下架商品
为什么不要用GORM的Save()直接转ES文档？
GORM模型结构和ES索引mapping往往不一致：MySQL字段可能是price decimal(10,2)，ES需要price: { "type": "scaled_float", "scaling_factor": 100 }；MySQL的tags varchar存逗号分隔字符串，ES期望"tags": ["a","b"]数组类型。硬映射会导致400 Bad Request或字段被丢弃。
性能影响明显：每次双写都做struct→map→JSON序列化，再经ES client二次序列化，CPU开销比直接构造map[string]interface{}高30%+。
- 定义专用ES文档结构体，如
type ProductEsDoc struct { ID uint `json:"id"` PriceCents int `json:"price_cents"` Tags []string `json:"tags"` } - 用
sql.NullString等GORM空值类型时，ES结构体对应字段必须可空（*string），否则JSON marshal会panic - 敏感字段（如密码、token）务必在ES文档构造阶段过滤，别依赖GORM的
gorm:skip标签——它对ES无效
位点丢失风险：GORM软删除 + ES同步的坑
GORM默认软删除（deleted_at非空），AfterDelete钩子不会触发，因为记录没真删。这时候ES还留着旧文档，而MySQL里已标记为删除，搜索结果就会出现“已下架但能搜到”的问题。
容易踩的坑：db.Unscoped().Delete(&product)确实能触发钩子，但会绕过GORM所有软删逻辑，破坏业务一致性；更糟的是，有些团队用UPDATE ... SET deleted_at=NOW()原生SQL更新，钩子完全收不到事件。
- 统一用
db.Select("id").Unscoped().Where("id = ?", id).Updates(map[string]interface{}{"deleted_at": time.Now()})替代原生SQL，确保钩子可捕获 - ES同步逻辑里显式判断
if product.DeletedAt.Valid，然后调用esClient.Delete()而非Index() - 定期跑对账脚本：对比
SELECT COUNT(*) FROM products WHERE deleted_at IS NULL和GET /products/_count?q=deleted_at:null，差值超过阈值告警
GORM与ES双写最麻烦的不是代码怎么写，而是“什么时候算真正完成”——MySQL commit只是起点，ES的refresh延迟、副本同步、bulk队列堆积都会让“已写入”变成“不可见”。别信任何“同步即实时”的承诺，生产环境必须按refresh_interval: 1s倒推可见性窗口，并在前端加loading态兜底。
