接口隔离原则是必须遵守的现实约束，核心是按调用方分组拆分胖接口，避免子类被迫实现无用方法；需渐进式重构，确保每个接口仅含1–3个强关联方法且被同一角色使用。
接口隔离原则不是“要不要做”的问题，而是“不做就容易在后期被子类实现拖垮”的现实约束。它不解决运行时性能，但直接决定你改一个功能时，要动多少个本不该碰的类。
什么时候必须拆接口：看子类是否在抱怨“我根本用不到这个方法”
典型信号是某个类实现接口后，throw new NotImplementedException() 出现了三次以上，或者注释里写着“此方法暂不支持”。这说明接口已经越界——它不再描述“这个角色能做什么”，而是在强行统一所有角色的行为。
- 比如
ICompanyDepartment要求所有公司都实现ITDepartment()和ManufacturingDepartment()，但 A 公司没产线、B 公司没 IT 团队，硬实现就是埋雷 - 再比如
ICustomerService里混着Refund()、UpgradePlan()、SendSurvey()，而客服坐席只处理退款，销售后台只管升级，运营系统只发问卷——它们本不该共用一个接口 - 判断依据很简单：如果两个类实现同一个接口，但各自只调用其中 1–2 个方法，其余方法永远不被消费，那这个接口就该拆
怎么拆：按调用方（client）分组，而不是按业务域分组
错误做法是把“用户相关操作”全塞进 IUserOperations，结果登录、注销、重置密码、导出报表全在里面。正确做法是看谁在用——Web API 控制器需要 ILoginService，后台任务需要 IUserExportService，权限中间件需要 IUserPermissionProvider。
- 每个接口只含 1–3 个强关联方法，命名体现角色，如
IWorker、IEater、IPayable - 避免
ICommonService、IBaseInterface这类泛化名，它们是 ISP 的天敌 - 允许接口继承（
interface IAdminWorker : IWorker, IApprover），但禁止“为复用而继承”，只因语义合理才继承
重构已有胖接口：别删，先加新接口再迁移
已有代码依赖大接口 IFullService，不能直接删掉它——那会炸掉整个调用链。稳妥路径是渐进式替换：
- 新建小接口
ISearchable、IEditable、IReportable，把对应方法从IFullService中移过去 - 让原实现类同时实现新旧接口（
class UserService : IFullService, ISearchable, IEditable） - 逐个修改调用方：把参数类型从
IFullService换成ISearchable，把字段类型也换掉 - 确认所有调用方都迁移完毕后，再把
IFullService标记为[Obsolete]，最后删除
容易被忽略的细节：接口不是越多越好，而是“刚好够用”
拆到只剩单个方法的接口（比如 ISendEmail、ISaveLog）看似极致，实则增加抽象噪音。真正关键的是“谁在用、为什么用、用几个方法”。一个 IOrderProcessor 包含 Validate()、ReserveStock()、ChargePayment() 是合理的——这三个动作天然串行，由同一上下文触发；但硬把 SendConfirmationEmail() 塞进去就不对，它属于通知层，应走 IOrderNotifier。
最常被跳过的一步是：写完新接口后，没去检查它的所有方法是否真的被同一组对象调用。只要发现某个方法长期只有测试代码或 Mock 在用，它大概率不该在这个接口里。
