服务定位器模式在PHP中易成反模式，因其隐式依赖全局容器，导致测试难mock、调用链路不透明、IDE无法提示、静态分析失效，且错误易扩散。
服务定位器模式在PHP里为什么容易变成反模式
它看起来能解耦，但实际会让类隐式依赖全局容器，测试时难 mock，调用链路不透明。比如 ServiceLocator::get('db') 这种写法，谁调用了什么、依赖了什么，只有运行时才知道。
更麻烦的是，一旦 ServiceLocator 自身逻辑出错（比如缓存没清、单例复用错实例），问题会散播到所有用它的类，排查成本高。
- 构造函数参数不体现依赖，IDE 无法提示、静态分析工具失效
- 单元测试必须提前注册服务，或 patch 全局状态，违背“隔离”原则
- 无法区分“可选依赖”和“必需依赖”，
get()返回 null 或抛异常都得手动处理
用依赖注入容器替代服务定位器的实操要点
不是简单换一个库，而是把“主动取”变成“被动给”。核心是让类只声明自己需要什么，由容器负责组装和传递。
以 PHP-DI 为例，关键不在配置本身，而在如何避免重蹈服务定位器覆辙：
- 禁止在业务类中直接调用
Container::get()—— 容器应只出现在启动入口（如index.php或框架引导文件） - 用类型提示声明依赖，而不是字符串名：
function __construct(Database $db, LoggerInterface $logger)，而非__construct($name = 'db') - 配置优先用 PHP 数组或属性注解，避免 XML/YAML 这类外部格式增加间接层
- 若需动态获取（如多租户场景下按请求切换 DB 实例），用工厂类封装，而不是让业务类直连容器
示例：一个需按环境加载不同缓存驱动的类，不该写 $cache = $container->get('cache.' . $env)，而应定义 CacheFactory，由容器注入该工厂并传入 $env 参数。
什么时候真需要“服务定位器”语义？用接口+委托更安全
极少数场景确实需要运行时决定服务实例，比如插件系统、策略路由。这时别手写全局单例，而是定义明确接口，把定位逻辑收口：
例如实现 PaymentStrategyLocator 接口，内部用数组映射策略名到具体类，但对外只暴露 locate(string $name): PaymentStrategy 方法。这个类本身由 DI 容器管理，并通过构造函数注入到使用方。
- 接口约束行为，避免随意
get()导致的类型不可知 - 定位逻辑可单元测试，不依赖全局状态
- 能加日志、缓存、fallback 等横切逻辑，而服务定位器通常只是裸 map 查找
- 如果某天要改成从数据库查策略配置，只需替换实现，调用方完全无感
Composer 包和框架集成中的常见陷阱
很多包文档写着“支持服务定位器”，实际是为兼容老项目妥协。比如 Laravel 的 app('cache') 或 Symfony 的 $this->get('logger')，虽可用，但一旦在非控制器/命令类中频繁调用，就等于悄悄退化成服务定位器模式。
- Laravel 中，避免在模型、资源类、数据传输对象（DTO）里调用
app()—— 这些类应该无框架依赖 - Symfony 的
ContainerAwareTrait已被标记为 deprecated，新项目必须用构造注入 - 第三方 SDK（如支付网关封装）若强制要求传入
ContainerInterface，说明它没遵循依赖倒置，最好自行包装一层适配器 - 使用
php-di/php-di时，注意autowire: true默认不解析接口实现，需显式配置->addDefinitions([...])绑定接口到具体类
真正难的不是写一个能工作的服务定位器，而是守住边界：哪些逻辑必须由容器启动时决定，哪些可以延迟到方法调用时才解析。越晚决定，灵活性越高，但失控风险也越大——这个分寸，没有配置能替你判断。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
