Find和First不能直接用于字典分页，因二者不处理offset/limit、总数统计及稳定排序，易致总条数缺失、跳页失败、重复/丢失记录；必须显式Count并共用相同查询条件，且Order须含唯一字段。
为什么 Find 和 First 不能直接用于字典分页
因为 GORM 的 Find 和 First 默认不支持分页逻辑，它们只负责查数据，不处理 offset/limit、总数统计、结构封装这些分页必需环节。硬套会导致前端拿不到总条数、无法跳页、甚至内存溢出（全表查再切片）。
常见错误现象：count error: unsupported driver: sqlite3（用 SQLite 时漏配 Count 方式），或分页后 Total 恒为 0，或不同页出现重复/丢失记录（没加稳定排序）。
- 必须显式调用
Count获取总数，且注意它和后续Find要共用相同查询条件（包括Where、Joins、Order） -
Order必须包含唯一字段（如id或组合主键），否则 MySQL 在OFFSET场景下结果不稳定 - 避免在
Find前用Limit+Offset直接拼分页——GORM v1.23+ 推荐用Scopes封装，更易复用
如何用 Scopes 封装可复用的字典分页逻辑
把分页参数提取成函数，配合 Scope（v1.x）或 Func（v2.x），让每个字典模型都能一键接入。核心是把 page、pageSize、where 条件解耦出来，不写死 SQL。
示例（GORM v2）：
func Paginate(page, pageSize int) func(tx *gorm.DB) *gorm.DB {
return func(tx *gorm.DB) *gorm.DB {
offset := (page - 1) * pageSize
return tx.Offset(offset).Limit(pageSize)
}
}
<p>// 使用时
var dicts []SysDict
var total int64
db.Model(&SysDict{}).
Where("status = ?", 1).
Count(&total).
Scopes(Paginate(page, pageSize)).
Find(&dicts)
-
Paginate函数返回的是*gorm.DB修饰器，不是执行动作，所以能链式调用 -
Count必须在Scopes之前调用，否则只统计了分页后的数量 - 如果字典表有软删除（
DeletedAt），确保全局启用Unscoped()或显式Where("deleted_at IS NULL")，否则Count和Find结果不一致
Scan vs Find：什么时候该用结构体，什么时候该用 map[string]interface{}
通用字典接口往往不需要强类型绑定（比如前端只关心 code、name、sort 字段），用 map[string]interface{} 可省去为每个字典建 struct 的成本，但要注意 GORM 对 map 的支持限制。
关键差异：
-
Find(&[]map[string]interface{})可用，但Count不支持 map 类型参数，仍需传*int64或*int - 字段名默认按数据库列名映射（如
dict_code→"dict_code"），若想转成驼峰（dictCode），得提前用db.Session(&gorm.Session{DryRun: true}).Model(&T{}).Statement.ReflectValue手动映射，不推荐 - 性能上无本质差别，但 map 写法更容易漏掉
Order导致分页错乱，建议至少固定写Order("id ASC")
MySQL 分页偏移过大时的性能陷阱与替代方案
当 page 达到万级，OFFSET 100000 会让 MySQL 扫描并丢弃前 10 万行，即使有索引也很慢。这不是 GORM 的问题，而是 SQL 层面的通病。
- 首选游标分页（cursor-based）：用上一页最后一条的
id作为下一页起点，例如WHERE id > ? ORDER BY id LIMIT 20，GORM 中只需改Where条件，无需改分页函数 - 若必须用页码，可在字典表加覆盖索引：
CREATE INDEX idx_status_id ON sys_dict(status, id)，让Count和Find都走索引 - 避免在分页查询里
JOIN大表，字典通常单表查询，如有关联字段（如分类名），优先用应用层查，而不是数据库LEFT JOIN
真正麻烦的不是写几行代码，而是确认你的字典查询是否真的需要支持跳转到第 500 页——多数管理后台“下一页”就够了，过度优化反而增加维护负担。
