接口应由调用方定义并持有，实现方仅实现且不反向依赖；接口包路径属调用方，禁止暴露实现细节、框架注解及运行时反射注入，参数宜封装为DTO，粒度按业务变化原因聚合。
接口本身不降低耦合，用错方式反而加重依赖——关键在谁定义接口、谁实现、谁持有引用。
接口定义方必须是调用方（稳定方），而非被调用方
常见错误是让服务提供者（比如 PaymentService）自己定义 IPayment 接口，再让上层模块去依赖它。这导致上层被绑定在具体实现的抽象上，违反“依赖倒置”。正确做法是：订单模块（调用方）定义 IChargeProcessor，支付模块只实现它，且不反向引用订单代码。
- 接口包路径应归属调用方模块，例如
com.example.order.contract，而非com.example.payment.api - 编译期检查：若支付模块的
pom.xml里声明了对订单模块的compile依赖，说明定义权错了 - IDE 中 Ctrl+Click 接口名，跳转目标应在调用方工程内，而不是实现方
避免在接口中暴露实现细节（如异常类型、返回值包装类）
接口方法抛出 AlipayApiException 或返回 AlipayResponseDTO，等于把支付宝 SDK 的细节泄漏给所有调用者，后续切换微信支付时需改接口、改所有实现、改所有调用点。
- 统一用业务语义异常：只抛
PaymentFailedException，由实现类内部转换原始异常 - 返回值用最简 POJO，如
ChargeResult（含success、traceId、message），不带三方字段 - 不要在接口里加
@RequestBody、@JsonIgnore等框架注解——那是实现层的事
运行时注入必须通过构造器或 setter，禁用 ServiceLoader 或静态查找
用 ServiceLoader.load(IChargeProcessor.class) 或 ContextHolder.getBean(IChargeProcessor.class) 会隐式引入容器耦合和反射风险，测试时无法干净替换实现。
立即学习“Java免费学习笔记（深入）”；
- Spring 场景下，用构造器注入：
public OrderService(IChargeProcessor processor) - 非 Spring 场景（如 CLI 工具），手动 new 实例并传入：
new OrderService(new WechatChargeProcessor()) - 禁止在接口实现类里调用
System.getProperty("payment.type")做分支判断——逻辑应上移到组合层
接口粒度要匹配“变化原因”，不是越小越好
把 charge()、refund()、query() 拆成三个接口看似更正交，但实际中它们总是一起变更（比如都增加风控参数），结果要同步改三个接口、三个实现、三处注入，反而提高维护成本。
- 按业务能力聚合：一个
IPaymentProcessor覆盖完整支付生命周期 - 按部署边界划分：如果退款走独立服务，再单独抽
IRefundService，否则保持同接口 - 接口方法参数建议用单个
ChargeRequest对象，而不是 5 个原始参数——便于后续扩展字段且不破坏签名
最难的不是写接口，而是说服团队接受“接口属于使用者”这个反直觉规则；最容易被忽略的是：接口一旦发布，修改成本远高于实现类重构——所以定义前多画一次时序图，比写十行实现更重要。
