接口是对“谁该做什么”的明确约定，定义能力边界与协作规则，体现责任而非实现，支撑解耦、可测性及团队并行开发。
接口在面向接口编程中不是技术细节，而是对“谁该做什么”的明确约定。它不关心实现，只定义能力边界和协作规则，是系统各部分之间达成信任的基础。
接口定义的是责任，不是实现
一个接口描述的是一组行为承诺，比如 PaymentProcessor 接口声明了 process(amount) 和 refund(id)，意味着任何实现者都必须提供这两个功能，并保证其语义一致——而不是规定用支付宝还是数据库事务来完成。
- 调用方只依赖接口签名，无需了解底层逻辑
- 实现方可以自由替换（如从模拟支付换成微信支付），只要契约不变，系统其他部分完全无感
- 违反接口语义（比如 process() 不扣款却返回成功）比代码报错更危险——它破坏的是协作信任
接口驱动设计与协作节奏
在团队开发中，接口常作为前后端、模块间或服务间的“合同初稿”。先共同敲定接口，再并行开发，能大幅减少后期联调冲突。
- 前端可基于接口文档写 Mock 数据，提前开发界面和交互逻辑
- 后端按接口契约开发，测试时用接口类型做断言，而非具体类名
- 接口变更需评估影响范围，必要时版本化（如 PaymentProcessorV2），避免静默破坏
接口是解耦与可测性的支点
没有接口，单元测试往往被迫依赖真实外部服务或复杂对象；有了接口，就能注入轻量模拟实现（Mock 或 Stub），让测试聚焦于逻辑本身。
- 例如测试订单服务时，把 InventoryService 接口用内存实现代替真实库存系统
- 测试用例可精确控制接口返回值（如“库存不足”、“网络超时”），覆盖各种边界场景
- 重构实现时，只要接口不变，原有测试仍全部通过，形成安全网
接口不是越多越好，关键是恰如其分
过度拆分接口会导致碎片化（如为每个方法建一个接口），而过于宽泛又削弱约束力（如一个 EverythingService）。好接口应满足单一职责，且由使用方驱动定义。
- 从调用方视角出发：“我需要什么能力？” 而非 “我能提供什么方法？”
- 接口粒度宜粗不宜细：一个 UserRepository 比 LoadUserById、SaveUser、DeleteUser 三个独立接口更易维护
- 接口名体现角色与意图（如 NotificationSender），而非技术手段（如 SmtpClient）
接口的价值不在语法，而在它迫使开发者思考“关系”与“承诺”。写好一个接口，等于为一段协作写下清晰的宪法。
