分页查询不触发beforecreate等写操作钩子，仅afterfind会在每条记录加载后逐条执行；其误用易致性能下降、静默失败或破坏软删除语义。
分页查询本身不触发任何钩子
GORM 的 Limit 和 Offset 是纯查询修饰符，只影响 SQL 的 LIMIT 和 OFFSET 子句，不会调用 BeforeFind 或 AfterFind 以外的任何钩子。也就是说：db.Limit(10).Offset(20).Find(&users) 不会触发 BeforeCreate、BeforeUpdate 等写操作钩子——这点常被误认为“分页时钩子异常失效”。
但注意：AfterFind 是唯一可能介入分页查询的钩子，它在每条记录从数据库加载进 struct 后立即执行，无论是否分页。
-
AfterFind对分页结果是逐条调用的，不是批量一次性触发 - 如果
AfterFind中做了耗时操作（如 HTTP 请求、文件读取），分页响应会明显变慢 - 若结构体字段未导出（首字母小写）或类型不匹配，
AfterFind里对字段的修改不会反映到最终Find结果中
AfterFind 钩子在分页中的典型误用
很多人想用 AfterFind 做数据脱敏或权限过滤，比如“仅对当前用户可见的字段赋值”。但在分页场景下容易踩坑：
- 它无法跳过某条记录——
AfterFind发生在记录已加载之后，不能像Where那样参与 WHERE 条件计算 - 若在
AfterFind中 panic 或返回 error，GORM 默认忽略（除非显式启用logger.Error级别日志），导致静默失败 - 对指针字段（如
*string）做赋值时，若原字段为nil，需先初始化，否则仍为nil
示例错误写法：
func (u *User) AfterFind(tx *gorm.DB) error {
if u.Status == "inactive" {
u.Name = "" // ✅ 可行，Name 是 string
*u.Email = "" // ❌ panic: u.Email 是 *string 且为 nil
}
return nil
}
分页 + 软删除时钩子行为易混淆
启用软删除（即含 DeletedAt 字段）后，Find 默认自动过滤已软删记录，这个过程不走任何钩子；但如果你手动加 Unscoped() 做分页查全部（含软删），就可能触发意外逻辑：
-
Unscoped().Limit(10).Offset(0).Find(&users)会把软删记录也加载进来，此时AfterFind仍会执行 - 但
AfterFind里无法区分该记录是“正常存在”还是“已被软删”，除非显式检查u.DeletedAt.Valid - 更危险的是：若你在
AfterFind里调用了tx.Model(u).Updates(...)，可能意外更新软删记录的字段，破坏软删除语义
真正影响分页性能的钩子隐患
最隐蔽的问题来自 AfterFind 中隐式触发的 N+1 查询——尤其当分页结果包含关联字段且未预加载时：
- 比如
User有BelongsTo关联Department，但没写Preload("Department") - 分页查 20 条用户，
AfterFind里又调用u.Department.Name→ 触发 20 次额外 SELECT - 这种问题在单条测试时不易暴露，一上分页就暴雷
解决方式只有两个：要么用 Preload 提前加载，要么在 AfterFind 中避免访问未加载的关联字段。别指望 GORM 自动优化——它不会为你重写 SQL。
