游标分页是智慧医疗随访系统的底线要求：因数据高频更新、复杂查询和无限滚动，offset分页易致漏数、重复、卡顿；应改用基于主键或时间戳的游标查询，确保order by字段有唯一索引支撑。
直接用 Limit + Offset 做分页，在智慧医疗随访场景下极易出问题：患者数据高频更新（如新增随访记录、状态变更）、查询条件复杂（多表 JOIN、模糊搜索）、前端无限滚动加载——这些都会让传统分页漏数据、重复、卡顿甚至拖垮数据库。
为什么 Offset 分页在随访系统里特别危险
智慧医疗随访数据有强时间敏感性和高写入频率。比如一个糖尿病患者每天生成 1 条血糖记录，后台定时任务又批量更新随访计划状态。此时：
-
Offset(5000).Limit(20)不是“查第 251 页”，而是“跳过前 5000 条再取 20 条”——但跳过的那 5000 条可能刚被新插入的随访记录挤到前面，导致某条关键预警记录永远不出现 - 医生在 Web 端翻到第 100 页时，
OFFSET已达 1980，MySQL 要扫描近 2000 行才能定位起点，响应从 20ms 涨到 1.2s - 多个护士同时操作同一患者队列（如标记“已电话随访”），
ORDER BY created_at DESC若无唯一索引支撑，两次分页结果顺序可能不一致，造成界面闪烁或重复提醒
用游标分页替代 Offset，必须基于主键或时间戳
随访列表本质是按“最新随访时间”或“患者 ID”线性推进的，适合游标分页。关键不是换库，而是改查询逻辑：
- 前端不再传
page=5，而是传上一页最后一条的cursor=12345（对应follow_up.id）或cursor=2026-08-20T14:22:01Z（对应follow_up.updated_at） - 后端查询写成：
db.Where("id > ?", cursor).Order("id ASC").Limit(pageSize).Find(&followUps)—— 不依赖偏移量，只查增量 - 必须确保
ORDER BY字段有索引，且组合唯一（例如(updated_at, id)，避免毫秒级时间重复） - 首次请求无 cursor 时，用
WHERE updated_at + <code>ORDER BY updated_at DESC, id DESC安全兜底
GORM 分页封装要避开三个坑
哪怕你决定暂时沿用 Offset，也得手动控制链路，别依赖第三方 Paginate 封装：
- 总数查询和列表查询必须拆开：用
db.Model(&FollowUp{}).Where(...).Count(&total)单独查，不能复用带Limit的 db 实例，否则 WHERE 条件会污染 -
Page和PageSize必须校验：前端传page=-1或page_size=10000会直接触发全表扫描，应强制截断为min(p.PageSize, 50) - 禁止在分页查询中用
Preload("Patient")：随访表 JOIN 患者表本身已含必要字段；若真要扩展信息，应查出 ID 列表后，用db.Where("id IN (?)", patientIDs).Find(&patients)批量查，避免 N+1
真实随访接口里 Order By 怎么写才稳定
排序字段选错，分页就不可靠。在随访场景下：
- 优先用
ORDER BY updated_at DESC, id DESC：updated_at记录状态变更时间，id保证唯一性，二者组合索引能覆盖绝大多数查询 - 避免只用
created_at：批量导入随访计划时，多条记录created_at完全相同，GORM 返回顺序不确定 - 不用
status排序：状态字段低基数（如 “待随访”、“已完成”），B+ 树索引区分度差，分页性能差且易跳页 - 如果业务要求“未读优先”，把逻辑下沉到 WHERE：
WHERE (read_at IS NULL AND updated_at > ?) OR read_at IS NOT NULL，再统一按updated_at DESC排，别试图用ORDER BY CASE
游标分页不是“高级功能”，而是智慧医疗这类高可靠性场景的底线要求。Offset 可以用于内部管理后台的低频、小数据量查询，但面向医护/患者的实时随访列表，必须放弃页码思维，转向基于位置的增量拉取。
