GORM不提供原生分页方法，官方推荐手写Limit+Offset或游标分页；需校验page≥1、pageSize∈(0,100]，显式Order排序，总数查询须独立db实例，大数据量应切游标分页。
GORM 本身不是为垂直搜索引擎设计的，它不提供倒排索引、分词、相关性打分或高并发全文检索能力。把它当「垂直搜索引擎的底层分页数据源」用，本质上是把 GORM 当作结果集后处理层——即：搜索逻辑（如 Elasticsearch、Meilisearch、Typesense 或自研引擎）负责召回和排序，GORM 只负责根据搜索返回的 ID 列表（或游标）去查原始业务数据并分页组装。
这个定位必须先厘清，否则容易在架构上踩坑。
为什么不能直接用 GORM 做搜索分页？
因为 GORM 的 Limit/Offset 是对全表扫描做物理跳过，而垂直搜索的“第 N 页”语义不是“跳过前 (N-1)×size 行”，而是“在已排序的命中结果中取第 N 段”。两者数据视图完全不同：
- 搜索结果顺序由引擎算出（如 BM25、TF-IDF、向量相似度），
GORM无法复现该顺序 - 若用
GORM对原始表WHERE ... ORDER BY score DESC LIMIT ... OFFSET ...，score 字段根本不在数据库里，没法查 - 即使你把 score 存进 DB，更新延迟、一致性、索引失效都会让排序错乱
正确配置：GORM 只查 ID 后批量加载详情
典型流程是：搜索服务返回 []uint64{1001, 1002, ..., 1020}（第 1 页 20 条 ID），GORM 负责这一步：
- 用
db.Where("id IN ?", ids).Order(clause.OrderByColumn{Column: clause.Column{Name: "id"}, Desc: true}).Find(&items)查详情 —— 注意：Order 必须按ids的顺序还原，否则返回乱序；GORM v2.6+ 支持clause.OrderByColumn配合IN子句稳定排序 - 别用
Preload加载一对多关联（比如文章 → 标签），它会生成 N+1 查询；应先查出所有item.ID，再用单条SELECT * FROM tags WHERE article_id IN (?)批量加载，最后 in-memory 关联 - 如果搜索返回的是游标（如
last_score=0.92&last_id=1001），GORM不参与游标计算，只负责按新条件查下一页 ID 列表（这部分逻辑应在搜索客户端或网关层完成）
分页参数校验和透传必须由上层统一控制
前端请求形如 /search?q=go&cursor=abc123&page_size=15，但 page_size 和 cursor 的含义完全由搜索服务定义，GORM 层不能自行解析或转换：
-
GORM不接收page参数 —— 垂直搜索没有传统页码概念，只有游标或 offset（后者仅限小规模、低频更新场景） - 若搜索服务支持 offset 模式（如调试用），
GORM的Offset值应直接来自搜索响应头（如X-Search-Total+X-Search-Offset），而非前端 query - 所有参数校验（如
page_size > 100拒绝）必须在搜索网关或 handler 入口做，GORM层只信任上游已清洗过的 ID 列表或条件
性能关键点：ID 列表长度必须限制
搜索返回的 ID 数量就是 GORM 单次查询的 IN 长度，这个值失控会导致 SQL 报错或慢查询：
- MySQL 默认
max_allowed_packet限制IN列表长度，超长需分批（如每 500 个 ID 一次Find） - PostgreSQL 对
IN长度无硬限制，但超过几千项时计划器可能退化，建议同样分批 - 不要把搜索返回的全部 ID 一次性丢给
GORM；先len(ids) 校验，超限则返回 400 或自动截断
真正难的不是 GORM 怎么写，而是搜索服务和 GORM 之间那条边界划在哪——ID 怎么传、顺序怎么保、错误怎么透、分批怎么控。这些细节一旦模糊，线上就会出现“搜得到但展示为空”或“第 3 页开始数据重复”这类问题。
