uuid主键不能直接用于游标分页，因其字典序不等于插入顺序，导致where id > ? 查询结果不稳定、易跳过或重复记录；必须改用有索引的时间戳字段（如created_at）并配合主键构成复合游标，确保排序与分页一致性。
UUID主键无法直接用 id > ? 做游标分页，因为 UUID 是无序字符串，ORDER BY id ASC 不具备单调递增性——翻页时容易跳过或重复记录。必须改用时间戳字段（如 created_at）作为游标锚点，并确保该字段有索引、非空、精度足够。
为什么 UUID 主键不能直接用于游标分页
MySQL/PostgreSQL 对 UUID 字符串的字典序比较不等于插入顺序，尤其 v4 随机生成的 UUID；同一毫秒内插入多条时，created_at 相同但 UUID 无序，导致 WHERE id > 'xxx' 无法稳定界定“下一页”。常见错误现象：page=3 返回空数组，或某条记录在第 2 页和第 4 页重复出现。
-
ORDER BY id ASC在 UUID 主键上无法保证物理写入顺序，数据库返回结果不可预测 - 即使加了
INDEX(id)，B+ 树索引仍按字典序组织，不是时间序 - 前端传
cursor=uuid_v4_string后，后端执行WHERE id > ?可能匹配到几百条甚至零条，分页断裂
必须用 created_at + id 复合游标
真正可行的方案是把排序和游标都绑定到带索引的时间字段，并用主键兜底去重。例如：按 created_at DESC, id ASC 排序，游标传 last_created_at 和 last_id 两个值。
- 首次请求不带游标：
db.Order("created_at DESC, id ASC").Limit(21).Find(&users) - 后续请求条件必须同时满足：
WHERE created_at ?) - 对应 GORM 写法：
db.Where("created_at ?)", lastCreatedAt, lastCreatedAt, lastID).Order("created_at DESC, id ASC").Limit(20).Find(&users) -
created_at字段必须是DATETIME(3)或BIGINT时间戳，避免秒级精度导致大量相等值 - 复合索引必须严格匹配排序顺序：
INDEX idx_created_id (created_at, id)
Count 总数查询怎么避开 UUID 主键陷阱
UUID 主键本身不影响 COUNT(*)，但如果你在分页查询里用了 Joins 或 Preload，总数统计极易出错——因为 db.Model(&User{}).Count() 完全不感知关联逻辑。
- 别复用带
Joins的 DB 实例做 Count：db.Joins("JOIN profiles...").Count(&total)会忽略 JOIN 条件，结果虚高 - 简单场景用隔离会话：
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where("status = ?", "active").Count(&total) - 复杂关联必须手写子查询：
db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u LEFT JOIN profiles p ON u.id = p.user_id WHERE u.status = ?) AS t", "active").Scan(&total) - 如果前端只显示“下一页”，就别查总数——查
LIMIT 21，判断 len(users) == 21 决定是否返回has_next: true
UUID 分页还要防什么坑
除了排序和游标，UUID 主键在分页链路中还会放大几个隐蔽问题：Preload 关联加载失控、URL 编码失败、前端透传校验缺失。
- 别在分页查询里用
Preload("Orders")：GORM 会先查出 20 个 UUID，再拼成IN ('a','b',...)查订单，但 UUID 字符串过长可能超 MySQLmax_allowed_packet，直接报错 - 前端传的
last_id是 UUID 字符串，必须用base64.RawURLEncoding.DecodeString解码，不能直接uuid.Parse()—— URL 中的+和/会被篡改 - 后端收到游标值必须校验格式：
if !isValidUUID(lastIDStr) { return c.AbortWithStatusJSON(400, "invalid cursor") }，不能静默 fallback 到第一页 - 如果业务允许，把 UUID 主键降级为业务 ID，另建自增
sort_id字段专用于分页排序——这是最稳的物理解法
