下界通配符（? super t）不能实现权限继承，因其仅为编译期类型约束工具，不承载权限语义或运行时校验逻辑；权限继承需依赖authority层级建模、jwt预计算继承链、动态决策器等真实机制。
下界通配符（? super T）本身是 Java 泛型的类型系统机制，用于安全写入操作，它不直接参与权限继承、网关拦截或网络通信逻辑。把“下界通配符”和“权限继承链向下透传”混在一起，属于概念错位——前者是编译期类型约束工具，后者是运行时访问控制策略，二者不在同一抽象层级，也不能互相“实现”或“透传”。
为什么不能用 ? super T 实现权限继承
权限继承是业务逻辑层面的设计模式，常见于：
- 权限系统中 parentRole → childRole 的授权传递
- Spring Security 中 GrantedAuthority 的层级结构（如 ROLE_ADMIN 继承 ROLE_USER）
- Bukkit/Spigot 插件中 bukkit.command.* 对 bukkit.command.kick 的隐式覆盖
而 List super String> 这类声明只表达：“这个列表能存 String 或它的任意父类（比如 Object）”，它不携带任何权限语义，也不触发任何校验行为。编译器不会因你写了 ? super Permission 就自动把 root 角色的权限塞进子模块。
真正支撑权限向下透传的技术组合
企业级网关（如 Spring Cloud Gateway + Spring Security）中实现权限继承链，依赖的是以下真实机制：
-
Authority 层级建模：定义角色继承关系，例如
new SimpleGrantedAuthority("ROLE_ADMIN")和new SimpleGrantedAuthority("ROLE_USER")，再通过RoleHierarchyImpl配置ROLE_ADMIN > ROLE_USER -
Token 携带全路径权限：JWT 中不只放当前角色，而是预计算并注入继承链，如
"authorities": ["ROLE_ADMIN", "ROLE_USER", "PERM_API_READ"] -
动态权限决策器：自定义
AccessDecisionManager，在每次请求时检查目标资源所需权限是否被当前 token 的 authority 集合所覆盖（含继承） -
网关层预检缓存：对高频接口路径（如
/api/v1/order/**）建立权限映射表，避免每次转发都查 DB；继承关系在启动时加载并构建成前缀树或 DAG 图
泛型在权限系统中的合理用武之地
泛型可提升权限工具类的复用性，但需明确边界：
- 用
PermissionChecker super Resource>表示一个能校验 Resource 及其子类型（如 Order、Payment）的检查器 - 用
RoleBuilder<t extends role></t>构建带类型约束的角色配置器，防止误设非法字段 - 集合操作时用
Collection super PermissionAction>安全添加不同粒度的操作实例（如 ReadAction、WriteAction 都是 PermissionAction 子类）
这些用法不改变权限流向，只是让类型更稳、扩展更安全。
精简网关拦截规则的关键实践
减少重复配置、避免每层都做全量校验：
- 路由级统一鉴权：在 GatewayFilter 中解析 JWT，并将
authorities注入ServerWebExchange.getAttributes()，下游服务直接读取 - 路径前缀绑定权限模板：如
/admin/** → [ROLE_ADMIN]，/user/profile → [ROLE_USER, PERM_PROFILE_READ]，用 AntPathMatcher + Map 预加载匹配 - 拒绝默认继承：不开启
permitAll()或anonymous()除非明确需要；所有未显式放行的路径默认拦截 - 异常归一化：统一捕获 AccessDeniedException / AuthenticationException，返回标准错误码（如 40301 权限不足，40102 Token 过期），前端无需识别多种异常类型
