抽象类通过统一状态生命周期接口、封装通用校验逻辑、定义模板方法处理副作用、结合泛型枚举强化类型安全，间接保障多模块状态一致性。
在业务开发中，抽象类本身不直接“保持状态一致性”，但它能通过强制约束和统一契约，让各模块在状态管理上遵循相同逻辑，从而间接保障一致性。
定义统一的状态生命周期接口
把模块中涉及状态变更的关键行为（如初始化、校验、提交、回滚）抽成抽象方法，子类必须实现。这样所有模块的状态流转路径就天然对齐。
- 例如抽象类 BaseOrderProcessor 声明 validateState()、applyChanges()、rollback() 为 abstract
- 订单、退款、库存扣减等具体处理器继承它，各自实现时必须考虑“当前状态是否允许执行该操作”
- 避免出现 A 模块校验了库存余量而 B 模块直接更新数据库却不校验的不一致情况
封装共用的状态校验与转换逻辑
将跨模块通用的状态规则（如“待支付 → 已支付”是合法迁移，“已发货 → 待支付”非法）放在抽象类中实现，子类复用而非重复编码。
- 抽象类中提供 canTransitionFromTo(String from, String to) 方法，内置状态机规则表
- 子类调用 super.validateTransition(current, next) 即可完成合法性检查
- 后续新增状态或调整流程，只需改抽象类一处，所有子类自动生效
统一状态变更的副作用处理机制
状态变化常伴随日志、事件发布、缓存更新等副作用。抽象类可定义模板方法，确保这些动作总在状态落地前后按序执行。
- 抽象类定义 handleStateChange(oldState, newState) 模板方法，内含 preHook → updateDB → postHook 流程
- 子类重写 doUpdate() 和 emitEvent()，但无法跳过日志记录或事务边界
- 防止某模块忘了发 MQ 事件，或另一模块在 DB 更新前就清了缓存
配合枚举+泛型强化类型安全
用泛型限定子类必须使用同一套状态枚举，并结合抽象类中的泛型方法做编译期校验。
- 抽象类声明为 abstract class StatefulProcessor
> - 子类如 OrderProcessor extends StatefulProcessor
- 抽象类中 transitionTo(S target) 方法就能在编译时阻止传入错误枚举类型，减少运行时状态错位
不复杂但容易忽略：抽象类不是银弹，关键在设计初期就想清楚哪些是“必须一致”的状态行为，哪些是“可以差异”的业务逻辑。把前者锁死在抽象层，后者放开给子类发挥，系统才既稳定又可扩展。
