抽象类的核心价值在于统一行为契约、避免重复定义、防止调用散乱，通过集中管理共享状态、固化API调用流程、约束跨系统一致性，并规避初始化陷阱来实现。
抽象类的核心价值之一，就是把跨系统、跨模块共用的状态和调用规范“收口”到一个可继承、可约束的基类中。它不是单纯为了复用代码，而是为了统一行为契约、避免重复定义、防止调用散乱。
共享基类状态：集中管理通用字段与初始化逻辑
多个API客户端（如订单服务、用户服务、支付服务）往往共用 token、超时配置、重试策略、请求头等状态。把这些提取到抽象基类里，子类只需专注业务逻辑，不用反复声明或校验。
- 定义 protected 字段（如 protected String baseUrl、protected int timeoutMs），供所有子类直接访问
- 在抽象类构造器中完成基础初始化（如加载配置、校验必要参数），子类通过 super(...) 触发，确保前置条件一致
- 提供 final 方法封装通用行为，例如 final Response call(String path, Object body)，内部统一处理鉴权、日志、异常包装，子类只传路径和数据
规范API调用层级：用模板方法固化流程骨架
不同系统的HTTP调用看似差异大，但底层流程高度相似：准备请求 → 发送 → 解析响应 → 处理错误。抽象类可通过模板方法模式把不变的部分锁死，变化点留给子类实现。
- 定义 protected abstract HttpRequest buildRequest() 和 protected abstract T parseResponse(Response raw)，强制子类明确“怎么构参”和“怎么转模型”
- 主干方法 public final T execute() 内部按顺序调用 buildRequest() → send() → parseResponse() → handleSuccess()，中间任何环节出错都走统一 fallback
- 预留钩子方法，如 protected void onBeforeSend(HttpRequest req)，子类按需添加 traceId 或埋点，不破坏主流程
约束跨系统一致性：通过抽象方法+运行时检查双重保障
当多个团队对接不同外部系统（如银行网关、短信平台、风控引擎）时，容易出现命名不一、错误码处理混乱、重试逻辑各自为政等问题。抽象类能从设计源头卡住关键契约。
- 声明 public abstract String getSystemCode()，要求每个子类返回唯一标识（如 "bank-boc"、"sms-aliyun"），用于日志归集与监控路由
- 定义 protected abstract ErrorCode mapErrorCode(int httpCode, String body)，强制统一错误映射逻辑，避免各子类自己 if-else 硬编码
- 配合静态检查工具（如 Java 的 ErrorProne 或 TypeScript 的 strictNullChecks），让未实现抽象方法的子类在编译期就报错，不等到上线才发现缺失
避免常见陷阱：初始化安全与继承链清晰
抽象类一旦涉及状态共享和调用封装，初始化顺序和继承深度就变得敏感。稍有不慎就会导致空指针或行为错乱。
- 切忌在抽象类构造器中调用任何 abstract 方法 —— 此时子类字段尚未初始化，极易 NPE
- 若存在多层继承（如 BaseApiClient → FinanceApiClient → BankTransferClient），确保每层只负责一层职责，抽象方法逐级细化，不越级跳过
- 状态字段尽量设为 final 或不可变类型（如 ImmutableList），防止子类意外篡改影响其他调用方
