上界通配符（? extends T）用于安全读取，保证元素为T或其子类型且禁止写入（null除外），在报表引擎适配中精准表达“只读兼容性”，支撑统一抽象、解耦类型、提升适配器复用。
上界通配符（? extends T）在 Java 泛型中用于**安全读取**——它保证容器里所有元素都是 T 或其子类型，但禁止向其中写入（除 null 外）。在三方报表引擎的多格式数据流适配场景中，它的核心价值不是“炫技”，而是**精准表达“只读兼容性”语义**，从而支撑统一抽象、避免类型强耦合、提升适配器复用深度。
明确适配目标：报表引擎不关心数据源细节，只消费标准结构
三方报表引擎（如 JasperReports、DynamicJasper、甚至自研轻量引擎）通常只接受以下任一输入：
- 标准 JDBC ResultSet（最通用）
- List（键为字段名，值为任意类型）
-
自定义 Row 接口实现（如
RowData），含get(String field)和getTypes()
关键点在于：引擎只“读”字段名和值，不修改、不构造、不依赖具体实现类。这正是 ? extends RowData 的天然适用场域——你传一个 MySqlRow、ExcelRow 或 ApiJsonRow，只要它们都 extends RowData，引擎就能统一处理。
定义上界通配泛型的适配器接口
不暴露具体实现，只声明能力契约：
public interface DataStreamAdapter<T extends RowData> {
// 返回可安全遍历的只读行集合（? extends T 表达：你给我任何 T 子类的 List，我都认）
List<? extends T> fetchRows();
// 字段元信息，与具体行类型解耦
List<FieldMeta> getSchema();
}
这样设计后，一个 ExcelAdapter implements DataStreamAdapter<excelrow></excelrow> 和一个 ClickHouseAdapter implements DataStreamAdapter<clickhouserow></clickhouserow> 都能被同一份报表渲染逻辑调用，无需 instanceof 判断或强制转型。
实战中规避常见陷阱
上界通配符易用，但误用会导致编译失败或运行时异常：
-
别试图往 ? extends T 里 add：比如
List extends RowData> rows = adapter.fetchRows(); rows.add(new MySqlRow());→ 编译报错。正确做法是让适配器内部完成构造，外部只负责消费。 -
统一转换层放在适配器内，而非引擎外：不要写
List<rowdata> unified = rows.stream().map(...).collect(...)</rowdata>。应由适配器直接返回已对齐结构（如统一转成List<map object>></map>），或让引擎通过RowData::get统一读取——这才是“解耦”的本质。 -
配合工厂模式使用更自然：定义
interface AdapterFactory<t extends rowdata></t>，由 Spring 管理不同AdapterFactory<excelrow></excelrow>、AdapterFactory<csvrow></csvrow>实例，按配置动态加载，彻底隐藏类型细节。
为什么比泛型方法或 Object 更优？
对比其他方案：
-
用
Object+ 强转：丢失编译期类型检查，运行时 ClassCastException 风险高；IDE 无法推导方法签名，重构困难。 -
用泛型方法
<t> void render(T data)</t>：每次调用需显式指定类型，调用方仍需知道具体子类，复用性停留在“方法级”，非“组件级”。 -
用上界通配符接口：类型约束在接口定义层，实现类自由选择子类型，使用者只面向抽象编程。Spring 可自动注入
DataStreamAdapter extends RowData>的所有 Bean，报表服务只需一次@Autowired List<datastreamadapter extends rowdata>> adapters</datastreamadapter>即可聚合全部数据源能力。
本质上，上界通配符在这里不是语法糖，而是把“兼容性承诺”从文档写进类型系统，让复用从“靠人遵守约定”变成“靠编译器强制保障”。
