错误，仓储的saveAll方法不应使用Collection
在领域驱动设计（DDD）中，仓储（Repository）的 saveAll 方法接收参数时，应使用 extends（上界通配符），即 Collection extends AggregateRoot>，而非 Collection super AggregateRoot> 或裸类型。
为什么用 ? extends AggregateRoot？
因为 saveAll 只读取传入集合中的聚合根实例，不向其中写入新元素——它把数据“拿出来”持久化，而不是往集合里“塞东西”。PECS 原则（Producer Extends, Consumer Super）明确指出：若泛型参数仅作为生产者（只产出、只读取），就该用 extends。
-
saveAll遍历集合获取每个AggregateRoot的状态，用于插入或更新数据库 - 它从不向该集合添加、替换或修改元素（那是调用方的责任）
- 允许传入
ArrayList<order></order>、Set<payment></payment>等子类型集合，只要Order和Payment都继承自AggregateRoot
为什么不用 ? super AggregateRoot？
? super 适用于“消费者”场景（如向集合添加元素），但 saveAll 不需要往参数集合里写任何东西。若错误使用 Collection super AggregateRoot>，反而会限制传入类型——例如无法传入 List<order></order>（因为 Order 不是 AggregateRoot 的父类），违背了灵活性初衷。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
为什么不直接用 Collection<aggregateroot></aggregateroot>？
裸类型或固定上界会失去多态友好性。比如业务层常有 List<customer></customer> 或 Set<product></product>，它们都是聚合根子类的集合。若方法签名硬写成 Collection<aggregateroot></aggregateroot>，调用时就得显式转型或新建包装集合，既啰嗦又易错。
立即学习“Java免费学习笔记（深入）”；
- 正确签名：
<t extends aggregateroot> void saveAll(Collection<t> entities)</t></t>或更通用的void saveAll(Collection extends AggregateRoot> entities) - 前者支持类型推导（如返回值需泛型），后者更简洁，适合纯消费场景
实际编码建议
Spring Data JPA 的 JpaRepository.saveAll(Iterable<t>)</t> 就采用了类似思路（虽然用的是 Iterable<t></t> + 方法级泛型），DDD 自定义仓储可借鉴：
- 优先声明为
void saveAll(Collection extends AggregateRoot> entities) - 避免在方法内部对参数集合做修改（如 clear、add），否则破坏契约
- 若需同时支持保存和返回新 ID（如主键生成后回填），可改用泛型方法
<t extends aggregateroot> List<t> saveAll(Collection<t> entities)</t></t></t>，保持类型安全
