关键在于避免N+1、字段爆炸和条件拼接失控：用Scopes封装条件、Preload替代Joins防分页错乱、近似估算或缓存COUNT、白名单控制动态排序。
直接用 GORM 做设备台账多维分页查询，关键不在“能不能”，而在“怎么避免 N+1、字段爆炸、条件拼接失控”。默认的 Find 或 Limit/Offset 组合在多条件 + 关联表 + 大数据量下极易翻车。
多维条件组合时，别手写 SQL 拼接 where
常见错误是把前端传来的 status、category_id、keyword 全部用 if 判断后手动拼字符串。这既难维护，又容易漏转义、引号错位，还无法复用预编译语句。
- 正确做法：用
Scopes封装可复用的查询逻辑，比如ByStatus、ByKeyword -
ByKeyword内部统一用LIKE %?%+strings.TrimSpace防空值，不依赖外部判断 - 所有条件都走
Where链式调用，GORM 会自动跳过 nil/zero 值（如Where("status = ?", status).Where("category_id = ?", catID)，当catID == 0时可提前过滤或显式加catID > 0）
关联设备所属部门、供应商时，预加载必须用 Preload 而非 Joins
查设备台账常要带出 Department.Name 和 Supplier.Code。用 Joins("left join departments...") 看似简单，但一旦加上分页，MySQL 会先 JOIN 再 LIMIT，导致分页结果错乱（一条设备连 3 个部门，就占 3 行，LIMIT 10 实际只返回 4 条设备）。
- 必须用
Preload("Department").Preload("Supplier")，GORM 会拆成 3 次查询：主表分页查设备 → 查出的设备 ID 列表 → 批量查部门 → 批量查供应商 - 注意：如果部门/供应商表也需筛选（比如只查启用状态的部门），不能在
Preload里加Where，得改用Preload("Department", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", 1) }) - 避免嵌套过深：
Preload("Department.Parent")容易引发笛卡尔积，真需要时建议单独查或加缓存
分页性能瓶颈不在 LIMIT，而在 COUNT(*)
前端要求“显示总条数”，后端习惯性跟一句 Count(&total)。当设备表超百万行、且带多维条件时，这个 COUNT 可能比主查询还慢——尤其当 WHERE 条件没走索引，或涉及函数（如 DATE(created_at)）。
- 生产环境建议：对总条数做近似估算，比如用
SELECT TABLE_ROWS FROM information_schema.TABLES WHERE TABLE_SCHEMA = ? AND TABLE_NAME = ?（仅适用于无复杂条件的全表统计） - 更稳妥方案：条件稳定时，用 Redis 缓存各维度组合的 COUNT 结果，过期时间设为 5–10 分钟
- 如果必须精确总数，确保
WHERE中所有字段都有联合索引，例如(status, category_id, deleted_at)，且deleted_at IS NULL要写成deleted_at = ?（传nil）才能命中索引
字段动态排序要防 SQL 注入，别信前端传来的 order_by
用户想按“采购日期倒序”“设备编号升序”，后端直接拼 ORDER BY ? ? 是高危操作。GORM 不允许参数化列名和方向，硬拼等于裸奔。
- 白名单控制：定义合法字段映射表，如
map[string]string{"purchase_date": "purchase_date", "code": "code"}，前端传sort=code，查不到就 fallback 到默认字段 - 方向限定：只接受
asc/desc，其他一律转asc；不要用fmt.Sprintf("ORDER BY %s %s", field, dir)，而应Order(clause.OrderByColumn{Column: clause.Column{Name: field}, Desc: dir == "desc"}) - 注意：GORM V2 的
Order不支持表达式，如LENGTH(code)，这种必须回落到Session(&gorm.Session{DryRun: true})获取 SQL 后手工处理
真正麻烦的不是写完查询，而是当“按使用部门+启用状态+模糊名称”三个条件组合上线后，DBA 突然告诉你慢查询日志里全是这条——这时候索引是否覆盖、Preload 是否触发了额外 JOIN、COUNT 是否被优化，才见真章。
