接口定义能力契约，抽象类封装可复用接入骨架：接口提供稳定、正交、易测的能力入口；抽象类内置通用字段、强制构造约束、封装模板流程并复用工具方法；实现类通过extends抽象类+implements多接口实现能力叠加。
在 Java API SDK 设计中，抽象类与接口的组合使用不是为了“凑够语法”，而是为了解决 SDK 的核心矛盾：既要保持调用方轻量简洁，又要让集成方灵活可扩展。关键在于——接口定义能力契约，抽象类封装可复用的接入骨架。
接口定义统一能力入口，屏蔽实现差异
SDK 对外暴露的行为必须稳定、正交、易理解。这类能力适合用接口定义：
-
能力粒度清晰：比如
PaymentClient接口只声明pay(ChargeRequest)和refund(RefundRequest)，不暴露重试、签名、序列化等细节 - 支持多实现：用户既可用官方 HTTP 实现，也能替换为 gRPC 或本地模拟实现，只要符合接口契约即可
-
便于版本演进：后续加
default void cancel(ChargeId id)不破坏老版本 SDK 的编译兼容性 - 利于 Mock 与测试：调用方直接依赖接口，单元测试时可轻松注入 Stub 实现
抽象类提供标准接入骨架，降低集成门槛
当多个 SDK 实现共享相同流程、状态或初始化逻辑时，抽象类是不可替代的支撑：
-
内置通用字段：如
protected final Config config、protected final HttpClient httpClient，避免每个实现重复声明和校验 -
强制构造约束：抽象类可要求子类传入
AppKey和Secret，确保关键凭证在实例化阶段就位（接口无法做到） -
封装模板流程：例如
public final Response execute(Request req)固定执行“签名→序列化→HTTP 调用→异常转换→日志记录”，仅留protected abstract HttpRequest buildHttpRequest(...)由子类定制 -
复用非 public 工具方法：如
protected String hmacSign(String data)可被子类安全调用，但不对外暴露
组合方式：先 extends 再 implements，支持能力叠加
具体 SDK 实现类采用单继承 + 多实现方式，这是 Java SDK 架构的标准范式：
-
写法唯一正确：
class AlipayClient extends AbstractHttpClient implements AsyncCapable, Retryable, Tracable - 每个接口代表一个正交能力维度：异步支持、自动重试、链路追踪、指标上报等，可按需启用，互不影响
-
抽象类已实现的逻辑可与接口 default 方法协同：比如
Retryable提供轻量default void retry(...)，而抽象类中已有带熔断策略的重试引擎，子类可选择复用或覆盖
避免常见陷阱：职责不清导致维护成本飙升
SDK 设计中最容易踩的坑，是模糊抽象类与接口的边界：
- 不为继承而继承：若某个抽象类仅含一两个空方法，不如直接删掉，交给接口 default 方法处理
-
不强行让抽象类实现接口：除非该抽象类天然具备该行为且能提供合理默认实现（如
AbstractRestClient实现HttpClient接口），否则会增加理解负担 -
警惕方法冲突：若抽象类有
public void start()，而某接口也有default void start()，子类必须显式@Override并决定调用哪一方逻辑
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
