抽象类是模板方法模式的基石，它封装算法固定部分并用抽象方法预留可变环节；模板方法必须定义在抽象类中且用final修饰，内部按序调用抽象与具体步骤，如支付回调中parseRequest、verifySignature由子类实现，其余复用。
抽象类是模板方法模式的基石，它把算法中固定不变的部分封装起来，同时用抽象方法预留可变环节，让子类专注实现差异逻辑。
抽象类承担算法骨架职责
模板方法必须定义在抽象类中，因为只有抽象类才能既提供具体实现（如公共校验、日志记录、资源清理），又声明未实现的方法供子类覆盖。抽象类不负责完成整个流程，而是明确“先做什么、再做什么、最后做什么”，比如：
- 统一处理请求头解析和响应封装
- 强制执行事务开启与提交/回滚逻辑
- 在数据导出前自动校验权限，导出后触发通知
抽象方法标记子类定制点
抽象类中声明的抽象方法，就是模板方法里留出的“插槽”。它们没有方法体，只定义签名，子类必须实现——这保证了流程完整性，也避免了空实现或误调用。常见命名习惯包括：doProcess、validateInput、buildResult等，语义清晰，便于识别扩展位置。
模板方法本身需用final修饰
为防止子类意外重写流程顺序，模板方法应声明为final。它内部按严格次序调用若干步骤：部分是抽象方法（由子类实现），部分是已实现的具体方法（父类提供默认行为）。例如：
- prepare() —— 父类提供默认初始化
- execute() —— 抽象方法，子类实现核心逻辑
- cleanup() —— 父类确保资源释放
实际应用中的典型结构
以支付回调处理为例：抽象类定义handleCallback()为final模板方法，内部依次调用parseRequest()（抽象）、verifySignature()（抽象）、transferFunds()（具体）、updateOrderStatus()（具体）。不同支付渠道（微信、支付宝）只需继承该抽象类，各自实现解析与验签逻辑，其余步骤完全复用。
