空结果是正常情况而非错误，Find()返回空切片且err==nil属预期行为，First()等查不到则返回gorm.ErrRecordNotFound；游标分页需校验last_id有效性，Offset分页应限制page参数并接受空结果为合法终态。
空结果是正常情况，不是错误
调用 db.Find(&users) 或 db.First(&user) 后 users 为空切片、user 为零值，不代表出错——这是 GORM 对「查无结果」的标准响应。很多人误以为要 panic 或返回 500，其实只要 err == nil，就该当作合法的空分页处理。
常见错误现象：前端传 page=1000，后端查不到数据，却抛出 record not found 错误并返回 404；或未检查 err 直接遍历空切片导致 panic。
- 用
Find()查列表时，空结果返回err == nil，len(users) == 0是预期行为 - 用
First()/Last()/Take()时，查不到会返回gorm.ErrRecordNotFound，但分页场景不该用这些方法 - 永远不要对
Find()的结果做if err != nil { return err }粗暴拦截——它不报错才是对的
游标分页下 last_id 无效导致空结果的判断逻辑
游标分页中，若前端传了非法或过期的 last_id（比如被篡改、已删除、类型不匹配），查询很可能返回空切片。这时不能直接返回 400，得先区分是「真没数据」还是「游标失效」。
关键做法：首次请求不带游标，后续请求强制校验 last_id 类型和范围，并在查询前加兜底验证。
- 用
strconv.ParseUint(lastIDStr, 10, 64)解析，失败则返回 400 - 解析成功后，先查一条
db.Where("id = ?", lastID).Select("id").First(&dummy)，确认该 ID 存在且未被软删 - 若不存在，说明游标已失效，可返回空结果 +
{"has_next": false}，而非报错 - 避免直接
Where("id > ?", lastID)后不校验就返回，否则用户刷新页面可能反复看到“无更多数据”
Offset 分页空结果与越界页码的防御性处理
db.Offset(offset).Limit(limit).Find(&users) 在页码过大时可能返回空切片，但这不等于数据库异常——更可能是 offset 超出总行数。此时需防止恶意构造超大 page 参数耗尽连接池。
- 必须校验
page和pageSize：如if page 100，直接拒掉 - 不依赖
Count()判断是否存在第 N 页（性能差），而是接受空结果为合法终态 - 若业务强依赖“是否还有下一页”，建议改用游标；若坚持 Offset，可查
Limit(pageSize + 1)，用 len 结果判断是否截断（多查 1 条成本远低于 Count） - 禁止把空结果日志记为 ERROR 级别——它应是 INFO 或 DEBUG
空结果下 JSON 序列化的零值安全
GORM 查询结果结构体字段若含指针或可空类型（如 *string, sql.NullString），空结果时这些字段为 nil，JSON 序列化默认忽略或输出 null。但前端常期望统一字段存在，哪怕为空字符串或 0。
- 避免在模型里大量用
*string，除非真需要区分“未设置”和“空字符串” - 对必须返回默认值的字段，用 struct tag 控制：
Name string `json:"name,omitempty"`→ 改成Name string `json:"name"`，Go 默认序列化空字符串 - 若字段可能为 NULL 且需映射为非空值，用自定义 Scan 方法或中间层转换，而不是靠前端兼容 null
- 空切片
[]User{}序列化为[]是正确行为，无需额外包装成{"data": []}—— 除非 API 规范强制要求
