入参用通配符可提升兼容性，返回值避免通配符以确保调用方安全使用；? extends t 适用于只读，? super t 适用于只写，而返回具体类型如 list 更利于调用方直接操作。
因为入参用通配符能放宽调用方传入类型的限制，而返回值用通配符会让调用方难以安全使用结果。
入参用通配符：提升兼容性，降低调用门槛
公共 API 的参数是调用方“交给你的东西”，越灵活越好。用 ? extends T 或 ? super T 能让不同子类或父类的集合都能传进来，不强制要求精确类型。
-
? extends T 适合只读场景（比如统计、遍历）：传
List<string></string>、List<charsequence></charsequence>都能接受 -
? super T 适合只写场景（比如收集、填充）：传
List<object></object>、List<serializable></serializable>都能接收T类型元素 - 不用通配符（如直接写
List<t></t>）会卡死——List<integer></integer>无法传给声明为List<number></number>的参数，哪怕逻辑上完全合理
返回值避免通配符：保证调用方能直接安全使用
返回值是“你交给调用方的东西”，必须明确、可预测。如果返回 List extends String>，调用方连 get(0) 都只能接成 Object，还得手动转型，极易出错且破坏类型安全。
- 返回
List<string></string>，调用方可以直接String s = list.get(0); - 返回
List extends CharSequence>，即使实际是ArrayList<string></string>，编译器也只允许CharSequence cs = list.get(0);，不能直接当String用 - 更糟的是
List super Integer>这类下界返回值：调用方根本不知道能取出来什么具体类型，只能当Object处理，失去泛型意义
本质是职责分离：参数负责接纳，返回值负责交付
参数面向“输入兼容”，目标是让别人容易调；返回值面向“输出确定”，目标是让别人放心用。PECS 在入参上做加法（扩展可接受范围），在返回值上做减法（收缩到最明确类型），正是这种设计哲学的体现。
- 阿里 Java 开发手册也明确建议：泛型方法返回值类型不应含通配符
- 标准库如
Collections.unmodifiableList()返回List<t></t>而非List extends T>，就是为调用方省去转型负担 - 一旦返回值用了通配符，调用方大概率要写冗余的 instanceof + 强转，违背泛型初衷
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
