接口隔离原则的核心是客户端不应依赖不需要的接口，需按业务角色、调用方能力边界拆分职责单一的小接口，避免胖接口与default方法滥用，通过接口组合构建灵活可维护的能力契约。
接口隔离原则（ISP）的核心是：客户端不应依赖它不需要的接口。在Java中，这意味着一个接口不应包含过多、过杂的方法，尤其不能强迫实现类去实现与自身无关的行为。关键不是“接口越少越好”，而是“每个接口职责单一、粒度合适、面向特定使用者”。
按业务角色拆分接口
同一实体可能在不同场景下承担不同角色，应为每种角色定义独立接口。例如订单系统中，Order对象既参与支付流程，也参与物流跟踪，还涉及售后处理：
-
PaymentCapable：只声明
pay()、refund() -
Trackable：只声明
getTrackingNumber()、checkStatus() -
Returnable：只声明
requestReturn()、cancelReturn()
这样，支付服务只需依赖 PaymentCapable，物流模块不感知退货逻辑，避免了“实现一堆空方法”或“抛出 UnsupportedOperationException”的反模式。
按调用方能力边界划分
外部系统、前端、内部服务对同一资源的访问权限和操作需求不同。接口应反映这种差异，而非统一暴露全部方法：
立即学习“Java免费学习笔记（深入）”；
- 面向移动端的
UserLiteService：仅提供getBasicInfo()、updateAvatar() - 面向管理后台的
UserAdminService：包含disableUser()、resetPassword()、auditLoginHistory() - 二者可共用同一实现类，但通过不同接口约束调用方行为
这种拆分天然支持权限收敛和API版本演进，后续新增字段或功能时，只影响对应接口，不破坏已有契约。
避免“胖接口”与默认方法滥用
Java 8+ 支持接口中定义 default 方法，容易诱使开发者把本该拆分的逻辑塞进一个接口里：
- 错误做法：在
DataRepository中同时定义save()、exportToExcel()、sendToKafka()、generateReport() - 正确做法：拆为
WritableRepository、Exportable、EventPublisher、ReportGenerator - default 方法仅用于真正通用、无副作用、且所有实现都可安全复用的逻辑（如日志埋点模板、参数校验工具方法）
若 default 方法体中出现条件判断（如 if (this instanceof Xxx)），说明接口已违背单一职责，必须拆分。
结合组合优于继承，用接口组合构建能力
一个类可通过实现多个小接口来声明其综合能力，比继承一个大接口更灵活：
class PremiumUser implements Identifiable, Payable, Notifiable, Exportableclass GuestUser implements Identifiable, Notifiable- 测试时可针对单个接口编写 mock（如只 mock
Payable行为），降低测试耦合度 - 未来扩展新能力（如
Subscribable）不影响现有接口使用者
这种组合方式让类型系统本身成为文档——从接口名就能推断对象能做什么，无需翻源码或查 Javadoc。
接口不是功能清单，而是契约声明。拆得合理，代码才易读、易测、易维护。
