通配符用于入参可拓宽兼容性，用于返回值则损害调用方安全性；根本区别在于数据控制权——入参由调用方提供，API声明能安全处理的类型边界；返回值由API生成，必须明确交付契约，确保调用方可预测、可安全使用。
API 入参用通配符能放宽调用方的类型约束，返回值用通配符却会让调用方难以安全使用——这背后是“谁控制数据流向”决定的。
入参用通配符：给调用方更多自由
方法接收数据时，通配符让 API 能兼容更宽泛的输入类型，而不会牺牲安全性：
-
? extends T：调用方可传
List<integer></integer>、List<bigdecimal></bigdecimal>等任意Number子类列表，方法内部只读取、转为doubleValue()等通用操作，不关心具体子类 -
? super T：调用方可传
List<object></object>、List<number></number>或List<integer></integer>，方法可放心add(new Integer(42))，因为目标容器明确承诺能容纳Integer -
?：连类型都不限定，适合日志、判空、遍历等完全与类型无关的操作，比如
void log(List> list)可接任何列表
这些设计不改变方法逻辑，只拓宽了合法输入范围，调用方无需改代码、不引入新依赖，自然提升跨模块或跨部门协作的兼容性。
返回值用通配符：把难题甩给调用方
一旦返回值带通配符，调用方立刻面临“知道有东西，但不敢用”的困境：
立即学习“Java免费学习笔记（深入）”；
-
List extends String>返回后，你无法确定它是不是ArrayList<string></string>还是LinkedList<yourstringsubclass></yourstringsubclass>，更无法安全地add("x")—— 编译器禁止写入 -
Map, ?> getProps()返回后，你连keySet()拿到的元素都只能当Object处理，无法调用toString()以外的任何方法，实际可用性极低 - 泛型擦除让运行时无法还原真实类型，调用方若想进一步处理，往往得靠
instanceof+ 强转，既破坏类型安全，又增加冗余代码
这不是扩展性，是推卸责任。API 的职责是提供清晰、可预测的结果，而不是返回一个“类型模糊的黑盒”。
根本区别在于数据控制权归属
入参由调用方提供，API 设计者只需声明“我能安全处理哪些输入”；返回值由 API 生成，设计者必须明确“我交付的是什么，你能怎么用”。
- 入参通配符 → 声明能力边界（我能读/写哪些类型）
- 返回值通配符 → 隐藏实现契约（我不告诉你具体是什么，你自己猜）
所以标准实践是：参数可宽，返回要窄。返回明确类型如 List<string></string> 或 Result<user></user>，调用方才能直接用、敢重构、易测试。
