GORM不内置脱敏与动态分页，须在SQL层先Select指定安全字段再Limit/Offset分页，避免内存泄露；应使用Scopes统一封装脱敏、分页和逻辑删除逻辑。
GORM 本身不提供数据脱敏能力，也无内置动态分页逻辑；脱敏必须由业务层显式控制字段读取，分页则需手动组合 Limit 和 Offset 或用 Scopes 封装——二者叠加时，脱敏逻辑若放在分页之后，会导致未脱敏数据短暂暴露在内存中。
脱敏不能靠 SELECT *，必须显式指定安全字段
很多人误以为在模型 struct 上加 json:"-" 或gorm:"-" 就能防泄漏，但这是错觉：GORM 的 Find、First 等方法默认加载全部字段（包括敏感字段），仅 JSON 序列化时忽略。一旦你把 struct 传给日志、监控或中间件，密码、token、身份证号就可能被意外打印。
- 正确做法是始终用
Select()显式列出允许返回的字段，例如：db.Select("id,name,email,created_at").Find(&users) - 对不同角色定义不同字段集：管理员查
id,name,email,phone,role，普通用户只查id,name,email - 避免在 DAO 层返回完整 struct 指针，改用 map 或专用 DTO 结构体，如
type UserSummary struct { ID uint; Name string; Email string } - 若用
Scan()，务必确认目标结构体不含敏感字段，且字段名与 SELECT 列严格对应
动态分页必须在脱敏前完成，否则内存中残留原始数据
常见错误是先 Find(&results) 拿到全量 struct 切片，再循环脱敏——这等于把所有敏感字段都加载进内存，哪怕后续没用到。尤其当一页只显示 10 条，但单条记录含 2KB 脱敏字段时，内存浪费和泄露风险陡增。
- 分页应作为 SQL 层操作：用
Limit(offset).Offset(limit)让数据库只返回需要的数据行 - 脱敏字段必须参与
Select()链路，即：db.Select("id,name,email").Limit(10).Offset(20).Find(&users) - 不要写
db.Find(&users).Limit(10).Offset(20)—— GORM 不支持这种链式顺序，Find已触发查询，后面调用无效 - 若需总数，用
Count()单独查：db.Model(&User{}).Where("deleted_at IS NULL").Count(&total)，注意这里也要同步加脱敏条件（如排除敏感状态）
用 Scopes 统一封装“脱敏 + 分页 + 逻辑删除”三重过滤
硬编码每处 Select + Limit + Where("deleted_at IS NULL") 容易遗漏。GORM 的 Scopes 是唯一可靠方式，把规则收口到一处，且能组合复用。
- 定义通用 scope：
func SafeList(db *gorm.DB) *gorm.DB { return db.Select("id,name,email,created_at").Where("deleted_at IS NULL") } - 定义带分页的 scope：
func WithPagination(db *gorm.DB, page, pageSize int) *gorm.DB { return db.Limit(pageSize).Offset((page - 1) * pageSize) } - 组合使用：
db.Scopes(SafeList, func(db *gorm.DB) *gorm.DB { return WithPagination(db, 2, 10) }).Find(&users) - 注意：scope 内部不能直接调用
Find，否则会提前执行；它只负责修饰 *gorm.DB 实例
别在分页后做字段级脱敏，更别依赖 middleware 拦截响应体
有人试图在 Gin 中间件里遍历 c.JSON 的 data 字段做正则替换，这既不可靠（JSON 已序列化为字节流）、又低效（重复解析）、还危险（可能破坏嵌套结构）。真正的边界在 DAO 层输出那一刻。
- middleware 只能做粗粒度拦截，比如拒绝
/api/users?fields=ssn这类非法参数，无法替代字段白名单 - DTO 结构体字段名必须与前端约定一致，避免用
json:"ssn"标签却在 Select 中漏掉该字段——GORM 不会报错，只会静默设零值 - 测试时重点验证：空字段是否真为零值（不是空字符串）、时间字段是否已格式化、分页 offset 越界时是否返回空切片而非 panic
- 最易忽略的是关联查询：用
Preload加载Profile时，必须确保Profile模型自身也走Select或定义了独立的脱敏 scope
