抽象方法不能强制实现二阶段提交契约，但能建模约束参与者行为：通过抽象基类定义prepare/commit/rollback等抽象方法，配合模板方法固化流程、注解与编译校验强化契约，并对接jdbc/xa或消息队列等底层资源实现统一语义。
抽象方法本身不能“强制实现二阶段提交契约”，但它能有效建模和约束分布式事务框架中参与者的行为规范——关键在于用抽象类封装协议骨架，把 prepare、commit、rollback 等核心生命周期动作声明为抽象方法，让具体资源（如数据库连接、消息队列客户端）必须提供符合 2PC 协议语义的实现。
抽象方法定义 2PC 的契约边界
在设计事务参与者（Participant）抽象基类时，应只暴露协议必需的、不可绕过的接口。例如：
- prepare()：必须完成本地事务预写日志（WAL）、资源锁定、状态持久化，并返回布尔值表示是否就绪；不允许直接提交或释放锁
- commit()：仅在收到全局 commit 指令后执行最终提交，且需保证幂等；不能依赖 prepare 阶段未落盘的状态
- rollback()：必须基于 prepare 阶段记录的上下文回滚，不能因本地事务已超时而自行丢弃
- 禁止提供 execute()、doCommitNow() 等破坏两阶段语义的非标准方法
通过模板方法固化协议流程
抽象类内部用模板方法（Template Method）控制整体流转，把不可变逻辑与可变实现分离：
- 定义 executeTwoPhase() 为 final 方法，内部按序调用
this.prepare()→ 收集响应 → 决策 →this.commit()或this.rollback() - 子类无法重写该流程，只能实现抽象方法；哪怕某数据库驱动想跳过 prepare 直接提交，编译期就会报错
- 可在模板中统一注入日志追踪 ID、超时检查、异常分类处理，确保所有参与者遵守同一观测契约
结合注解与编译期校验强化契约
仅靠抽象方法还不够，需配合其他机制防止误用：
- 为抽象方法添加自定义注解如
@PhaseBoundary，配合 APT 工具在编译期扫描，校验是否所有子类都覆盖了全部 2PC 方法 - 在抽象基类构造器中注册 SPI 服务发现逻辑，要求每个实现类声明其支持的 XA 资源类型（如
JDBC、Kafka），避免混入非 2PC 兼容资源 - 禁止子类重写
toString()或equals()来掩盖事务状态，抽象基类可将这些方法设为 final 并返回标准化元信息
与实际框架对接的关键细节
落地时需注意抽象契约与底层资源的对齐方式：
- 对于 JDBC 数据源，
prepare()应映射到XAResource.start()+prepare()调用，而非简单执行 SQL - 对消息中间件（如 RocketMQ），
commit()必须触发endTransaction(COMMIT)，且需确保半消息状态机与本地事务日志一致 - 抽象层要屏蔽不同资源的差异，比如 MySQL 的 XA 和 PostgreSQL 的两阶段提交语法不同，但对外暴露统一的 prepare/commit 接口
