接口隔离原则要求客户端只依赖所需最小接口，避免“胖接口”（定义过多方法但仅用部分）；PHP 中应按职责拆分为小而专的接口（如Authenticatable、MailSender），结合类型提示与依赖注入实现松耦合、易测试。
接口隔离原则（Interface Segregation Principle，ISP）在 PHP 中强调：客户端不应依赖它不需要的接口，即一个类对另一个类的依赖应建立在最小接口上，避免“胖接口”带来的耦合和冗余。
什么是“胖接口”？
当一个接口定义了过多方法，而实现类只用其中几个时，这个接口就被称为“胖接口”。比如定义一个 UserServiceInterface，里面同时包含 login()、sendEmail()、generateReport()、exportData() 等方法，但某个控制器只调用 login()，却被迫实现或依赖全部方法——这违反了 ISP。
PHP 中如何体现接口隔离？
核心是拆分接口，按职责粒度定义小而专的接口：
- 把用户认证相关方法单独抽成 Authenticatable 接口（含
login()、logout()） - 邮件发送逻辑归入 MailSender 接口（含
send()、queue()） - 报表生成独立为 ReportGenerator 接口（含
build()、formatAsPdf()）
这样，登录控制器只需 implements Authenticatable 或依赖该接口类型参数，不感知其他能力。
立即学习“PHP免费学习笔记（深入）”；
结合 PHP 类型提示与依赖注入
Laravel、Symfony 等框架天然支持 ISP。例如在控制器构造方法中：
public function __construct(
private Authenticatable $auth,
private MailSender $mailer
) {}
而不是传入一个大而全的 UserManager 实例。这种写法让依赖清晰、可测、易替换——单元测试时可分别 Mock 认证行为或邮件行为，互不影响。
常见误区提醒
不是“接口越多越好”，而是“按需拆分”。过度拆分（如每个方法一个接口）会增加维护成本；也不应为了隔离而牺牲语义一致性（比如把 create() 和 update() 拆到不同接口，可能违背业务上下文）。关键看调用方是否真正存在“只用一部分”的场景。
