分页必须显式指定 order by，否则结果不可靠；offset 越大越慢，建议限制最大页码；page 和 pagesize 需校验；gorm 分页需检查 error 字段。
分页必须显式指定 Order By，否则结果不可靠
GORM 的 Limit 和 Offset 本身不保证顺序，数据库在无 ORDER BY 时返回行序是未定义的——同一查询多次执行可能拿到不同数据，跳页或重复数据就由此而来。
实操建议：
- 所有分页查询前加
Order("id ASC")或业务主排序字段（如created_at DESC） - 避免用
ORDER BY RAND()分页，性能极差且无法稳定分页 - 如果按非索引字段排序（如
status），注意 MySQL 可能全表扫描，分页深了会变慢
Offset 越大越慢，10 万条后明显卡顿
MySQL 执行 OFFSET 100000 时，仍需扫描前 10 万行再丢弃，CPU 和 I/O 压力陡增。这不是 GORM 的问题，是 SQL 分页的通病。
实操建议：
- 前端限制最大页码（如只允许查前 1000 页），后端校验
page * pageSize - 真要查深层数据，改用「游标分页」：用上一页最后一条记录的
id做条件，例如WHERE id > ? ORDER BY id ASC LIMIT 20 - 不要依赖
Count查总条数做「共 N 页」展示，高并发下开销大；可改用估算（如SELECT COUNT(*) FROM table WHERE ...加缓存）或隐藏总页数
GORM v2 分页写法容易漏掉 Error 检查
很多人直接链式调用 Limit().Offset().Find()，但 Find() 返回的是 *gorm.DB，错误藏在 error 字段里，不显式检查就可能静默失败。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
常见错误现象：
- 查不到数据却不报错，
result是空 slice，但err非 nil（比如字段名写错、表不存在） - 用
Scan()替代Find()时更易忽略err
正确写法示例：
var users []User
err := db.Order("id DESC").Limit(20).Offset((page-1)*20).Find(&users).Error
if err != nil {
// 处理 err，不是忽略
}
Page 和 PageSize 参数必须校验，别信前端传来的任何值
用户可能传 page=-1、page=999999999、pageSize=0 或非数字字符串，GORM 不做参数清洗，直接拼进 SQL 可能触发语法错误或 DoS。
实操建议：
- 用
strconv.Atoi转换并判断错误，拒绝非法数字 -
page至少为 1，pageSize限定范围（如 1–100） - 对超大
pageSize（如 > 1000）直接返回错误，不交给数据库执行 - 如果用 Gin 等框架，可在中间件统一校验，避免每个 handler 重复写
分页看着简单，真正上线后出问题的，八成卡在排序缺失、Offset 性能崩塌、或者参数没校验——尤其是那个被忽略的 Error 字段，它不会喊你，但会在凌晨三点默默让接口返回空数组。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
