泛型嵌套应注重结构分层、命名达意与边界明确，按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 object>>>();</string>—— 右侧已明确结构，var让变量名成为焦点 - ❌ 避免：
var data = new HashMap();—— 编译器推成原始类型，IDE 失去提示，后续put可能出错 - 命名补类型：用
pendingNotificationsByUserId替代map1，比写满屏泛型更易懂
嵌套结构优先封装成具名类型
三层以上的泛型嵌套（如 Map<string list>>></string>）直接出现在方法签名或字段中，会严重干扰阅读：
- 定义清晰的中间类型：
public record UserNotificationConfig(Map<string list>>> rules) {}</string> - 把权限图谱节点建模为
PermissionNode<tenant order read maskingcontext></tenant>，而不是裸写Map<string map set>>></string> - 封装后，业务逻辑里操作的是语义化类型，编译器还能帮你检查层级是否错位
避免通配符裸用，加类型边界收口
泛型嵌套中滥用 ? 容易导致类型穿透，尤其在权限、配置等强约束场景：
- ❌ 少用：
Permission, ?>—— 失去资源类型和动作枚举的校验能力 - ✅ 改为：
Permission extends Resource, ? extends Action>，配合接口如interface FieldResource extends Resource{}强制收敛 - 对外提供只读视图时，用
Collections.unmodifiableList()包一层，防止调用方意外修改深层结构
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
