PHP项目耦合高的根源在于硬编码依赖（如new Database()），解耦关键为三步：提取类名、用接口约束、容器运行时注入。
直接说结论：PHP项目耦合高，不是因为没写够代码，而是依赖关系写死了——比如 new Database()、Logger::getInstance() 或硬编码调用 PaymentProcessor::alipay()。解耦的关键动作就三个：把具体类名从代码里抠出来、用接口约束行为、靠容器在运行时塞进去。
为什么 new 一个对象就埋下耦合隐患
每次用 new 实例化，等于把类名和创建逻辑钉死在调用处。一旦要换数据库驱动、切日志存储方式或加新支付渠道，就得全局搜 new，改完还容易漏。
- 更隐蔽的问题是：这类代码没法单元测试——你不能让测试替你执行真实的数据库连接或发短信
- 如果这个类构造函数带参数（比如
new Cache($redis, $ttl)），调用方还得知道怎么配$redis实例，职责错乱 - 某些框架（如 Laravel）会自动绑定接口到实现，但如果你自己手写
new，这层抽象就彻底失效了
用接口 + 依赖注入替代硬依赖
不是不用设计模式，而是先做最基础的“解耦手术”：把依赖声明从实现类升级为接口，再通过构造函数传入。
- 定义
interface PaymentGateway，让AlipayGateway和WechatGateway都实现它 - 订单服务类
OrderService的构造函数接收PaymentGateway $gateway，而不是AlipayGateway - 真正创建实例的逻辑，挪到容器配置里（例如 PHP-DI 的
ContainerBuilder或 Laravel 的bind()） - 这样切换支付渠道，只需改一行容器配置，不碰业务代码
工厂模式别滥用，优先交给容器自动装配
看到需要“根据条件创建不同对象”，很多人第一反应是写个 PaymentFactory::create($type)。但多数时候这是多余动作。
- PHP-DI 的自动装配能直接解析构造函数类型提示，
new OrderService(new AlipayGateway())这种手动拼接完全可被$container->get(OrderService::class)替代 - 只有当创建逻辑真复杂（比如需读配置、校验环境、组合多个依赖），才值得单独抽工厂类；否则工厂本身又成了新耦合点
- 若必须用工厂，确保它返回的是接口类型（
function create(): PaymentGateway），而非具体类
观察者模式比 if-else 更适合扩展横切逻辑
登录后要记录日志、发通知、更新统计——这些不是登录主流程的核心，但硬塞进 login() 方法里会让它越来越臃肿。
- 定义事件接口
interface EventDispatcher，核心流程只调$dispatcher->dispatch(new UserLoggedIn($user)) - 监听器（
LoginLogger、NotificationSender）各自实现handle(UserLoggedIn $event)，彼此隔离 - 新增需求？写个新监听器，注册到容器，不用动原有登录逻辑
- 注意：事件对象本身应轻量，避免传大数组或资源句柄；监听器内抛异常不要中断主流程（可用 try/catch 包裹）
最难的不是选哪个模式，而是判断“这里到底值不值得抽象”。一个简单脚本里给 Database 加接口纯属浪费；但当同一套用户逻辑要跑在 CLI、API、队列三种上下文里，接口和依赖注入就不是选项，是刚需。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
