gorm通过gorm标签控制字段读写权限：:false禁止读取，
怎么用 GORM 字段标签控制读写权限
GORM 本身不提供「按角色动态开关字段」的能力，但能通过 gorm struct tag 在结构体层面硬编码字段级读写策略——这是最轻量、最可控的起点。别指望运行时靠角色切换某个字段是否入库，那是 ORM 层之上该做的事。
常见错误是把 Password 字段设成 gorm:"type:varchar(100)" 就完事，结果登录接口直接返回明文密码；或者更新用户时没拦住 UpdatedAt 被前端传值覆盖。
gorm:"：仅创建时写入（如 <code>Name），更新时不参与UPDATE语句gorm:"->:false;：创建时可写，但从不从 DB 读回（适合 <code>Password）-
gorm:"->"：只读字段（如CreatedAt、UpdatedAt），禁止手动赋值 -
gorm:"-"：完全忽略字段（如临时计算字段FullName），不建表、不读写
注意：这些标签只影响 GORM 的自动 SQL 构造，不防 SQL 注入或绕过中间件的非法请求。它们是“防御纵深”的第一层，不是权限闸门。
如何让不同角色看到不同的字段集合
字段可见性必须在查询后、序列化前做裁剪，不能靠数据库或 GORM 自动完成。GORM 的 Select() 方法可以指定字段列表，但它是静态的——你得根据当前用户角色动态拼。
比如管理员查用户列表要显示 email 和 last_login_at，普通用户只能看 name 和 avatar_url。这时候不能用一个 User 结构体来回塞数据，而应定义多个 DTO：
-
UserPublic：所有角色都可见的基础字段 -
UserAdminView：含敏感字段，只用于 admin 角色逻辑 - 查库时用
db.Table("users").Select("name, avatar_url").Find(&users)控制原始数据
别在 User 结构体里加 if role == "admin" { ... } 这类逻辑——结构体是数据契约，不是业务分支容器。
GORM Preload 权限关联时为什么总漏数据或 N+1
RBAC 场景下用 Preload("Roles.Permissions") 容易翻车，根本原因是外键缺失或 JOIN 条件不匹配。比如用户没绑任何角色，Roles 字段就是 nil，后续 Permissions 就不会加载，而不是空 slice。
更糟的是，如果 role_permissions 表里有脏数据（如指向已删的 permission_id），GORM 默认静默跳过，导致权限“消失”但无报错。
- 确保
user_roles.role_id和role_permissions.role_id都有外键约束，并设ON DELETE CASCADE - Preload 前先用
Joins("JOIN user_roles ...")显式写 JOIN，配合Where过滤无效绑定 - 查权限时别依赖嵌套 Preload，改用两次查询：先查用户角色，再用
IN批量查对应权限（SELECT * FROM permissions WHERE id IN (?)）
这比“一口气 Preload 全链路”更可控，也更容易加缓存。
权限校验和 GORM 查询怎么避免重复查库
典型陷阱是：中间件里查一次用户 + 角色 + 权限 → 业务 handler 里又查一遍用户详情 → 再次 Preload 关联数据。三次查询可能命中同一行，但 GORM 不会自动复用前序结果。
解决方式不是靠 GORM 缓存，而是靠 context 透传预加载结果：
- 登录成功后，一次性查出用户完整信息（含
Roles和每个 Role 对应的Permissions.Code列表） - 塞进
context.WithValue(ctx, "user_perms", map[string]struct{}{"user:read:own": {}}) - 后续所有 GORM 查询都基于这个权限上下文做字段裁剪或条件过滤，不再查权限表
真正难的不是写对 GORM 语句，而是让权限决策点（中间件）、数据读取点（repository）、序列化点（DTO 转换）共享同一份权限快照——否则再准的标签也救不了逻辑分裂。
