sql权限角色动态加载与按角色过滤数据的核心是将用户身份、角色和 数据访问 规则在查询时实时关联，而非硬 编码；通过 role_permissions、user_roles 等配置表实现权限动态扩展，统一数据访问层自动注入行级过滤条件与列级裁剪，并结合两级缓存与主动失效保障权限实时性。
sql 权限 角色动态加载与按角色过滤数据，核心在于把用户身份、角色和 数据访问 规则在查询时实时关联，而不是硬 编码 或静态配置。
角色权限表设计要支持动态扩展
别用固定字段存“是否管理员”这类布尔值。建一张 role_permissions 表，记录角色（role_id）、资源类型（如 table_name、data_scope）、操作（select/UPDATE）、条件表达式（可选）；再配一张 user_roles 关联用户和角色。这样加个新角色、调一条权限，不用改代码。
- role_id、resource_type、action 是必填，用于基础控制
- filter_condition 字段存类似 “dept_id = ?” 或 “tenant_id = ?” 的 字符串，运行时带入当前用户上下文参数
- 避免在表里存完整 SQL 片段，只存安全的条件骨架，防注入
查询时自动拼接角色过滤条件
不是每个 SQL 都手动写 WHERE dept_id IN (SELECT dept_id FROM user_depts …)。用统一的数据访问层（如 mybatis 拦截器、spring Data JPA 的 @Query + 自定义 Repository），在执行前解析 SQL，识别目标表，查出当前用户拥有的角色对应的数据范围条件，再动态注入 WHERE 或 JOIN。
- 例如：用户属于“华东销售组”，该角色绑定 filter_condition = “region = ‘east'”，查 orders 表时自动加上 AND region = ‘east’
- 多角色时取交集（严格模式）或并集（宽松模式），由业务定，默认建议并集
- 对聚合查询、子查询、视图也要 递归 处理，不能只扫主表
敏感字段按角色做行级 + 列级双控
有些字段（如 salary、id_card）不是所有角色都能看。光靠 WHERE 过滤行不够，得结合列裁剪。可在查询构建阶段检查 SELECT 列表，比对当前角色的 column_permissions 表，把无权字段替换成 NULL 或加密占位符。
- 比如 HR 角色能看到 salary，普通员工看不到 → SELECT name, CASE WHEN has_col_perm(‘salary’) THEN salary ELSE NULL END AS salary
- 列权限也走配置表，不写死在 Mapper xml 或 @Query 注解里
- 注意 ORM 框架的 懒加载、关联查询可能绕过列控，需统一拦截
缓存与刷新要匹配角色变更节奏
角色权限变了，不能等缓存自然过期。用户登录、切换角色、后台改权限时，主动清除该用户相关的查询缓存（如 redis 中以 user_id:roles 或 user_id:perms 为 key 的条目）。
- 权限变更频率低 → 用简单 key 清除，不用消息队列
- 高 并发 场景下，可加一层本地缓存（Caffeine）+ 分布式 缓存（redis）两级，本地设短 TTL，分布式设长 TTL 并配合主动失效
- 避免“刚授予权限却查不到数据”，关键路径上加日志确认权限加载是否成功
基本上就这些。重点不在技术多炫，而在于权限逻辑从 SQL 里抽出来，变成可配、可查、可审计的数据规则。
