不能直接用 paginate 方法拉取路径节点，因其是第三方插件、底层仍用 limit+offset 且掩盖参数校验漏洞，gorm v2.6+ 后还可能静默漏数据；必须配 order 防顺序混乱，总数查询需隔离 db 实例，超10万节点须改用游标分页。
为什么不能直接用 Paginate 方法拉取路径节点
因为 Paginate 不是 GORM 原生方法，而是第三方插件（如 github.com/joshbetz/pagination）提供的封装。它底层仍是调 Limit + Offset，但会掩盖参数校验漏洞：比如传 page=0 不报错、page_size=0 在 SQLite 下可能查出全表、Offset 为负数直接 panic。GORM v2.6+ 的 Scope 行为变更后，老版本插件还可能静默漏掉部分路径节点——尤其当节点表有高频插入（如实时上报的 GPS 坐标点）时，漏数据风险极高。
Offset + Limit 必须配 Order，否则路径节点顺序混乱
物流路径节点依赖严格时序，比如“装货→出发→中转→签收”，如果查询没加 Order，数据库不保证返回顺序，同一页请求两次可能漏掉某个中转点，或重复返回同一坐标点。必须显式指定排序字段：
- 首选
Order("id ASC")：假设节点表主键id是自增且写入有序（如用AUTO_INCREMENT或sequence） - 次选
Order("created_at ASC, id ASC")：避免多条节点时间戳相同（GPS 上报并发常见），用id做二级排序兜底 - 禁用
Order("created_at DESC")单字段：时间重复时结果不可控，路径还原会错乱 - 别用
Order("RAND()")：性能爆炸，且无法做下一页衔接
总数查询必须隔离 *gorm.DB 实例，否则总节点数算错
常见错误是复用同一个 *gorm.DB 链查总数：db.Where("route_id = ?", routeID).Limit(20).Offset(40).Count(&total)，这返回的 total 永远 ≤ 20。正确做法是新建会话隔离上下文：
var total int64
db.Session(&gorm.Session{NewDB: true}).Model(&PathNode{}).Where("route_id = ?", routeID).Count(&total)
如果路径节点表涉及 Joins（如关联车辆、司机信息）或复杂条件（如 status IN ('active', 'pending')），建议手写子查询防 COUNT 错误：
db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM path_nodes WHERE route_id = ? AND status IN (?, ?)) AS t", routeID, "active", "pending").Scan(&total)
超过 10 万节点时，必须切游标分页
物流订单的路径节点量级容易突破百万（如一个长距离干线运输含每 5 秒一个 GPS 点）。此时 Offset(99999).Limit(100) 会让 MySQL 扫描并丢弃前 10 万行，响应从毫秒级升至秒级。游标分页才是可靠方案：
- 首次请求：用
db.Order("id ASC").Limit(100).Find(&nodes)，取nodes[len(nodes)-1].ID作为last_id - 后续请求：SQL 变为
WHERE id > ? ORDER BY id ASC LIMIT 100，前端传last_id而非page - 禁止在游标分页里混用
Preload：先查出本批节点 ID 列表，再用IN批量加载关联信息，否则会放大 N+1 问题 - 排序字段必须有索引：确保
id或(created_at, id)是联合索引，否则游标查询退化成全表扫描
游标分页真正难的不是写法，而是前端必须配合传递 last_id，且服务端要处理 last_id 不存在或被删除的边界情况——这点最容易被忽略。
