jsonb分页性能关键在索引与游标设计：必须为常用查询路径建gin或函数索引，优先用id+jsonb字段的复合游标分页，避免offset；count需独立会话或子查询确保准确。
JSONB 字段在 PostgreSQL 中支持高效查询和索引，但 GORM 对其分页没有特殊优化——分页逻辑仍走标准 Limit/Offset 或游标路径，只是 WHERE 条件里多了 JSONB 操作符。关键不在“怎么分页”，而在“怎么让 JSONB 查询可分页且不慢”。
PostgreSQL JSONB 查询必须加索引才能分页稳定
直接写 WHERE data->>'status' = 'active' 然后 ORDER BY id 分页，看似可行，但若 data->>'status' 没索引，每次分页都要全表扫描 JSON 字段，OFFSET 越大越卡。更糟的是，没索引时数据库无法保证排序稳定性，同一页可能漏数据。
- 必须为常用 JSONB 查询路径建 GIN 索引，例如：
CREATE INDEX idx_users_data_status ON users USING GIN ((data->>'status'));
- 若分页依赖 JSONB 字段本身排序（如
ORDER BY (data->>'score')::int DESC），得建函数索引：CREATE INDEX idx_users_score ON users (( (data->>'score')::int ));
- 复合排序更常见：比如
ORDER BY (data->>'score')::int DESC, id DESC，此时需联合索引覆盖两者，否则排序阶段会回表或文件排序
GORM 中 JSONB 条件 + Limit/Offset 容易踩的坑
用 Where("data->>'type' = ?", "vip") 配合 Offset/Limit 是可行的，但以下问题高频出现：
-
Where里混用?占位符和 JSONB 操作符（如@>、?）时，GORM 不做转义，容易 SQL 注入；应改用命名参数或预处理：db.Where("data @> ?", <code>{"tags": ["hot"]}</code>) -
Preload关联查询 + JSONB 条件时，COUNT(*) 总数统计会因 JOIN 膨胀失真；必须用子查询或Session(&gorm.Session{NewDB: true})隔离 COUNT -
Order("data->>'name') ASC在无索引时性能极差，且 PostgreSQL 对 JSONB 字符串排序默认按字节序，中文可能乱序；建议先转成COLLATE "zh_CN.utf8"或提前存规范化字段
JSONB 场景下优先用游标分页，别碰 Offset
当 JSONB 字段是业务主过滤条件（如用户配置、权限标签、动态表单），数据写入频繁，用 Offset 分页极易跳过或重复记录。游标必须基于确定性排序字段，而 JSONB 值本身往往不唯一——所以游标值要组合：
- 首选：主键
id+ JSONB 提取值（如(data->>'score')::int），构成复合游标：WHERE (data->>'score')::int > ? OR ((data->>'score')::int = ? AND id > ?) ORDER BY (data->>'score')::int DESC, id DESC LIMIT 20
- 前端传两个值：
last_score和last_id，后端拼 WHERE；首次请求只传last_id=0或不传，查最大 score 的前 20 条 - 切记：所有 JSONB 提取字段在游标中必须显式转换类型（
::int、::text），否则 PostgreSQL 会报错或隐式转换失败
总数统计在 JSONB 分页里常被误算
Count(&total) 看似简单，但在 JSONB 过滤场景下最容易出错：
- 错误写法：
db.Where("data->>'type' = ?", "vip").Limit(20).Offset(40).Count(&total)→ 返回永远 ≤ 20，因为Count继承了前面的Limit - 正确做法：用独立会话，且确保 WHERE 条件完全一致：
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where("data->>'type' = ?", "vip").Count(&total) - 更可靠（尤其带 JOIN 或复杂 JSONB 条件）：手写子查询，避免 GORM 链式污染：
db.Raw("SELECT COUNT(*) FROM users WHERE data->>'type' = ?", "vip").Scan(&total)
JSONB 分页真正的难点不在语法，而在索引设计与游标构造的耦合——一个没建对的 GIN 索引，会让所有分页变慢；一个没对齐的游标字段类型，会让下一页直接报错。别省这一步。
