泛型嵌套应注重结构分层、命名达意与边界明确，按PECS原则区分读写职责，善用var简化声明但保留类型信息，优先封装为具名语义化类型，并限制通配符裸用。
泛型嵌套写得清晰，关键不是堆砌类型，而是让每一层的“角色”和“意图”一目了然。重点在结构分层、命名达意、边界明确，而不是追求语法最短或最炫。
分层拆解，按 PECS 原则定读写职责
嵌套越深，越要一层层看清楚谁是生产者（只读）、谁是消费者（只写）：
- 外层用
? extends→ 表示你只打算从它里面取东西，比如List<? extends Number>可以安全遍历，但不能add() - 内层用
? super→ 表示你主要往里塞数据，比如List<? super Integer>能接受Integer、Number或Object，但取出来只能当Object用 - 像
List<? extends List<? super String>>这种，先拆成两段：外层是“某个能装List<? super String>的列表”，内层是“能存String及其父类的列表”——读外层得类型，写内层才安全
用 var 简化声明，但右侧必须带完整泛型
var 不是用来省类型信息的，而是消除重复噪音：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- ✅ 推荐：
var userConfigs = new HashMap<String, List<Map<String, Object>>>();—— 右侧已明确结构，var让变量名成为焦点 - ❌ 避免：
var data = new HashMap();—— 编译器推成原始类型，IDE 失去提示，后续put可能出错 - 命名补类型：用
pendingNotificationsByUserId替代map1，比写满屏泛型更易懂
嵌套结构优先封装成具名类型
三层以上的泛型嵌套（如 Map<String, List<Set<Long>>>）直接出现在方法签名或字段中，会严重干扰阅读：
立即学习“Java免费学习笔记（深入）”；
- 定义清晰的中间类型：
public record UserNotificationConfig(Map<String, List<Set<Long>>> rules) {} - 把权限图谱节点建模为
PermissionNode<Tenant, Order, Read, MaskingContext>，而不是裸写Map<String, Map<Long, Set<String>>> - 封装后，业务逻辑里操作的是语义化类型，编译器还能帮你检查层级是否错位
避免通配符裸用，加类型边界收口
泛型嵌套中滥用 ? 容易导致类型穿透，尤其在权限、配置等强约束场景：
- ❌ 少用：
Permission<?, ?>—— 失去资源类型和动作枚举的校验能力 - ✅ 改为：
Permission<? extends Resource, ? extends Action>，配合接口如interface FieldResource extends Resource{}强制收敛 - 对外提供只读视图时，用
Collections.unmodifiableList()包一层，防止调用方意外修改深层结构
