通配符和泛型方法各适其用：通配符适用于只读、类型约束宽松场景，泛型方法适用于需类型精确控制、参数联动或写操作的场景，二者常组合使用以兼顾灵活性与安全性。
通配符和泛型方法不是“谁更好”，而是“谁更合适”——关键看类型是否需要被约束、是否参与交互、是否要被复用。选错会导致编译失败或语义模糊，而不是运行时问题。
只读场景：通配符更轻量、更安全
当你只需要从集合中读取数据，且不关心具体类型（只要满足上/下界），通配符是首选。它不引入新类型变量，语义清晰，写法简洁。
- ? extends T：适合“生产者”角色，比如计算数字总和、遍历打印、校验长度等；不能 add 任何元素（null 除外）
- ? super T：适合“消费者”角色，比如把一批 String 写入一个可接受 CharSequence 的缓冲区；get 出来只能当 Object 用
- 不需要额外声明类型参数，调用方无需感知类型推导逻辑
需修改或类型联动：必须用泛型方法
一旦涉及写操作、多个参数间存在类型依赖、或返回值需与入参类型对齐，通配符就力不从心了。泛型方法能绑定真实类型，让编译器全程跟踪一致性。
- 例如：
<t> void copy(List<t> src, List<t> dst)</t></t></t>—— 两个列表必须是同一类型，通配符无法表达这种约束 - 又如：
<t> T pickFirst(List<t> list)</t></t>—— 返回值类型由 list 决定，? 无法支撑这种类型传导 - 泛型方法中的
T在调用时被具体化（如String），所以list.add(t)合法；而List extends Number>中的 ? 永远不确定，add 就被禁止
边界模糊时：混用是常态
实际工程中，二者常组合使用。通配符负责放宽输入兼容性，泛型方法负责内部类型精确控制。
- 典型模式：
<t> void process(List extends T> input, Consumer<t> handler)</t></t>—— 输入接受任意子类型，但处理器统一按 T 处理 - 再如 Collections.sort：签名是
<t extends comparable super t>> void sort(List<t> list)</t></t>，里面同时用了泛型参数T和嵌套通配符? super T，兼顾灵活性与类型安全 - 原则是：对外暴露尽量用通配符降低调用门槛，对内实现优先用泛型方法保障逻辑严谨
静态方法与泛型类的限制倒逼通配符出场
泛型类的类型参数在静态上下文中不可用，泛型方法就成了唯一选择；但若只是简单转发、无类型依赖，通配符反而更自然。
- 错误写法：
class Box<t> { public static T getStatic() { ... } }</t>—— 编译不过，T 在静态域无效 - 替代方案一（泛型方法）：
public static <t> T getFromBox(Box<t> b) { ... }</t></t> - 替代方案二（通配符）：
public static Object getFromBox(Box> b) { ... }—— 如果你只关心取出，不关心原类型，后者更直接
