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