pecs原则本质是“生产者用? extends t，消费者用? super t”：源表作为生产者只读行键，故用? extends r确保产出兼容；目标表作为消费者只写列键，故用? super c确保宽泛容纳，构成类型安全的数据流转管道。
Guava 的 Tables.transpose 方法没有直接暴露 PECS 原则的泛型签名，但它内部的类型推导与安全流转逻辑，本质上严格遵循 PECS 的设计思想——尤其体现在“读取源表行（生产者）”和“写入目标表列（消费者）”这一双向边界划分上。
源表格是 ? extends R：只读行键，保证产出兼容性
转置操作需遍历原表格的每一行。行键类型 R 在方法中被当作“产出端”使用：从 Table<r c v></r> 中取出某一行时，该行的键必须能作为目标表格的列键（即新表格的 C 位置）。但实际传入的可能是 Table<userid string order></userid>，而目标期望的是更宽泛的 Table<object charsequence order></object>。
因此，Guava 内部将源表格参数视为 Table extends R, ? extends C, V> 的变体（虽未显式写出通配符，但泛型推导强制要求 R 可向上兼容）。这确保：
- 取出的任意行键都能安全赋值给目标列键类型（只要目标列类型是其父类）
- 不允许多余写入——源表格不可被修改，符合“只读即生产者”的语义
目标表格是 ? super C：只写列键，支持宽泛接收
转置后，原行键变成新列键。目标表格需接受各种子类型行键作为列键，比如 UserId、AdminId 都应能塞进 Table, String, ?> 的列位置。
Guava 实际通过泛型方法签名隐式约束目标表格为 Table super C, ? super R, V> 结构（注意行列角色互换）：
- 新列键来自原行键 → 目标列类型需为 ? super R
- 新行键来自原列键 → 目标行类型需为 ? super C
这样设计允许：
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 把
Table<userid string order></userid>转置到Table<object charsequence order></object> -
dest.put(newColKey, newRowKey, value)总是类型安全——因为newColKey是R或其子类，而目标列接受? super R - 但不能假设
dest.column(newColKey).keySet()返回R类型——只能按Object处理，这是下界通配符的诚实表达
转置不是类型转换，而是边界对齐的数据重路由
Tables.transpose 不改变单元格值 V 的类型，也不做任何强制转型或中间包装。它只是重新组织键的归属关系：
- 原
table.get(r, c) = v→ 新transposed.get(c, r) = v - 所有类型安全性由编译器在调用点检查：若
R无法赋值给目标列类型，或C无法赋值给目标行类型，编译直接失败 - 避免了手动遍历 + 强转 +
put的易错模式，也绕开了Table<object object v></object>这类“全擦除”写法带来的运行时风险
对比手写转置：PECS 让签名更简洁、意图更清晰
若自己实现类似功能，典型错误是写成：
❌ 不安全public static <r> Table<c> transpose(Table<r> src, Table<c> dest)</c></r></c></r>→ 限制太死：只能传完全匹配的
Table<string></string>，无法接受 Table<userid></userid> 到 Table<charsequence></charsequence>而 Guava 的泛型推导等价于（简化示意）：
✅ 符合 PECSpublic static <r> Table<c> transpose(<br> Table extends R, ? extends C, V> src,<br> Table super C, ? super R, V> dest)</c></r>
→ 左边只读、右边只写，上下游各守其界，无需 cast，无运行时异常。
本质上，Guava 没有把 PECS 写在 API 表面，而是藏在类型变量约束与方法契约里——它让开发者专注“我要转什么”，而不是“我该怎么绕过泛型限制”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
