分页必须统一信源，禁用ES的from+size深度分页，改用search_after；GORM同步ES时避免Preload导致分页失真；总数统计需独立会话且条件严格一致。
分页不能混用 GORM 和 ES 的 offset 逻辑
GORM 的 Offset/Limit 和 Elasticsearch 的 from+size 看似等价，但底层行为完全不同：GORM 是数据库层跳行，ES 是协调节点合并分片结果后裁剪。一旦数据在 MySQL 和 ES 间存在同步延迟（哪怕几十毫秒），用相同 page/size 请求两者，返回结果大概率不一致——比如第 3 页都显示 10 条，但 ID 序列错位、总数对不上。
常见错误现象：
- 前端翻页时，某一页突然“重复出现”上一页的最后几条
- ES 返回 20 条，GORM 查同条件只查出 18 条，或反过来
- 总数统计不一致：
db.Model(&Blog{}).Where(...).Count()和es.Search().Query(...).Size(0).Do()结果差 1–N 条
根本原因不是代码写错，而是把两个异步系统当成原子操作。必须明确：分页锚点只能选一个系统作为唯一信源，另一个只做检索增强。
同步阶段必须禁用 ES 的 from+size 深度分页
ES 默认 max_result_window=10000，超过这个 from 值会直接报错 result window is too large。而 GORM 分页若不做游标改造，很容易在后台导出或管理端触发大 offset（如 page=500, size=20 → from=9980）。
实操建议：
- 所有面向用户的 ES 查询，强制使用
search_after替代from+size，且排序字段必须含id（如Sort("created_at:desc", "id:desc")） - 同步脚本里禁止用
from+size扫描全量数据；改用scroll或point-in-time (PIT)+search_after（ES 7.10+） - 如果业务允许，让 ES 只承担关键词检索，分页逻辑完全交给 GORM：先用 ES 拿到匹配的
[]int64{101, 205, ...}主键列表，再用db.Where("id IN ?", ids).Order("FIELD(id, ?)", ids).Find(&results)查详情并保序
GORM 查询结果写入 ES 时，避免 Preload 导致分页失真
很多人在同步时写类似 db.Preload("Tags").Preload("Author").Limit(20).Find(&blogs)，再把 blogs 全量推给 ES。问题在于：Preload 会触发 N+1 查询，实际加载的关联记录远超 20 条（比如 20 个博客，每个带 5 个标签 → 100 条 tag 记录），但 ES 索引只存了博客主体，搜索时却按完整结构建模，导致搜索结果和 GORM 分页列表语义割裂。
正确做法是分离“索引数据”和“展示数据”：
- ES 索引体只包含搜索强相关字段（
title,content,tags字符串数组，author_id整数），不嵌套 Author 结构 - GORM 分页查列表时，用
Select("id,title,content,author_id,tags")显式投影，避免多余字段拖慢查询 - 需要展示作者名时，前端或服务端用
author_id单独查一次缓存或 DB，而不是靠 ES 返回冗余数据
这样既能保证 ES 搜索性能，又能让 GORM 分页稳定可控。
总数统计必须走同一信源，且不可复用链式 DB 实例
最常被忽略的坑：为省事，在 GORM 分页查询后紧接着调 Count()，例如：
db.Where("status = ?", "published").Limit(20).Offset(40).Find(&blogs)
db.Where("status = ?", "published").Count(&total) // ❌ 错！这个 Count 会继承前面的 Limit/Offset
同样，ES 的总数也不能从 Search().Size(0) 和主查询共用同一个 elastic.SearchService 实例，否则可能因超时、重试策略不同导致计数偏差。
安全写法：
- GORM 总数查：用全新 session ——
db.Session(&gorm.Session{NewDB: true}).Model(&Blog{}).Where(...).Count(&total) - ES 总数查：独立构造
SearchService，显式设.Size(0)并检查res.Hits.Total.Value - 关键原则：总数和列表，必须从同一系统取，且二者查询条件 100% 一致（包括时间范围、状态码、软删标记等）
跨系统比对总数没有意义，只会掩盖同步延迟或逻辑不一致的问题。
