下界通配符（? super T）仅用于安全写入，限定集合可接收T及其父类实例，不参与撤销回滚逻辑；多级联动撤销依赖命令封装、状态快照、撤销栈及事务边界控制，与泛型通配符无关。
下界通配符（? super T）本身不参与撤销逻辑，也不能直接“平滑回滚状态”。它只是 Java 泛型中用于**安全写入**的类型约束机制，作用是限定集合能接收 T 及其父类 的实例。把它和“多级联动业务对象的撤销回滚”混在一起，属于概念错位——撤销流的核心是状态快照、命令封装与栈式管理，不是泛型通配符的使用场景。
真正支撑多级联动撤销的关键结构
复杂业务中多个对象状态相互依赖（比如订单→支付→库存→物流），撤销必须保证原子性与一致性。这靠的是：
-
命令对象封装变更：每个操作（如“扣减库存+锁定订单+生成支付单”）被打包为一个复合命令，包含
execute()和undo()两套逆向逻辑 -
统一状态快照或增量日志：不保存整个对象图，而是记录关键字段变更（如
order.status → "PAID"、stock.qty → -5），便于精准还原 - 撤销栈（UndoStack）与重做栈（RedoStack）分离管理：每次 execute 推入 UndoStack；undo 弹出并执行逆操作，同时压入 RedoStack
- 事务边界控制：用 CommandGroup 或 MacroCommand 包裹一组强关联操作，确保全部成功或全部回退，避免中间态残留
为什么下界通配符在这里不适用
有人误以为用 List<? super BusinessCommand> 可以“兼容各种撤销命令”，但实际会带来严重限制：
- 无法从中 安全读取具体命令类型，编译器只允许赋值为
null，不能调用undo() - 不能做
stack.pop().undo()—— 因为泛型擦除后类型丢失，且通配符禁止读取非 Object 方法 - 真实项目中撤销栈声明应为
Deque<UndoableCommand>或Stack<Command>，其中Command是明确接口，含execute()/undo()
一个轻量但可扩展的撤销设计示意
假设订单修改触发库存/优惠券/积分三联动：
- 定义
interface Command { void execute(); void undo(); } - 实现
OrderStatusChangeCommand、InventoryDeductCommand等，各自持有原始值与目标值 - 组合为
CompositeCommand，其undo()按反序调用子命令的undo() - 全局
UndoManager维护Deque<Command> undoStack，不涉及任何? super
泛型通配符解决的是容器写入时的类型安全问题，比如往 Collection<Object> 里 add 任意对象——但这和撤销流程无关。真要提升撤销可靠性，重点在命令粒度划分、状态隔离、错误回滚策略，而不是在集合声明里加 ? super。
