直接传参或依赖注入更可靠，因其逻辑透明、便于单元测试、支持ide跳转和类型提示；而service locator隐藏依赖、破坏可测试性、易引发注册顺序问题且类型不安全。
PHP 中对象跨层级传递问题，用 Service Locator 模式能解决，但不推荐作为默认方案——它容易掩盖依赖关系、破坏可测试性，只适合特定遗留场景或极简服务注册需求。
为什么直接传参或依赖注入比 Service Locator 更可靠
PHP 的函数调用栈深、请求生命周期短，new 或 require 时硬编码依赖虽显笨重，但逻辑透明；而 ServiceLocator::get('db') 这类调用会让调用方完全不知道自己依赖了什么，也难以在单元测试中替换 mock 实例。
- 控制器里调用
$user = UserRepo::find(1)，实际内部却通过ServiceLocator::get('pdo')获取数据库连接——这个pdo从哪来？谁注册的？什么时候注册的？全靠文档或全局搜索 - 测试时无法单独隔离
UserRepo，必须确保ServiceLocator已预注册pdo，否则直接抛出NullReferenceException或静默失败 - IDE 无法跳转到
pdo的定义，类型提示（PHPStan/ Psalm）也会失效，因为返回类型是mixed或靠注释硬写
如果非要用 Service Locator，必须手动控制注册时机和作用域
PHP 没有 Java 那样的 JNDI 上下文或容器自动扫描机制，所有注册都得显式做。常见错误是把 ServiceLocator::register() 写在某个类文件顶部，导致「注册顺序依赖」：A 类 require B 类，B 类又 require C 类，而 C 类注册的服务被 A 类提前用了。
- 注册操作统一放在
bootstrap.php或index.php入口最开始处，且按依赖顺序排列：先注册pdo，再注册cache（依赖pdo），最后注册user_repo（依赖前两者） - 避免在类构造函数里调用
ServiceLocator::get()—— 构造阶段无法保证服务已注册，应改用延迟获取（lazy getter）或 setter 注入 - 不要复用单例
ServiceLocator实例跨请求：CLI 脚本、Web 请求、队列任务生命周期不同，static $_services = []在 FPM 下可能残留上个请求的数据
替代方案：用 PSR-11 兼容容器 + 构造器注入更稳妥
现代 PHP 项目（如 Laravel、Slim、Mezzio）都支持 PSR-11 容器接口，它比手写 ServiceLocator 更规范，也更容易切换实现（如 php-di、container-interop）。
示例对比：
// ❌ 手写 ServiceLocator（脆弱、无类型、难追踪）
class ServiceLocator {
private static $services = [];
public static function register($key, $instance) { self::$services[$key] = $instance; }
public static function get($key) { return self::$services[$key] ?? null; }
}
ServiceLocator::register('logger', new FileLogger('/tmp/app.log'));
// ……其他几十行注册代码散落在各处
// ✅ PSR-11 容器（可配置、可类型约束、可自动解析）
$container = new \DI\Container();
$container->set(\Psr\Log\LoggerInterface::class, function () {
return new \Monolog\Logger('app');
});
$userService = $container->get(UserService::class); // 自动注入 Logger
- PSR-11 容器支持自动类型推导（如
__construct(LoggerInterface $logger)），无需字符串键名 - 可以绑定接口到实现（
$container->set(LoggerInterface::class, FileLogger::class)），便于换实现 - 支持工厂闭包、共享实例、生命周期管理，比静态数组灵活得多
Service Locator 真正适用的少数场景
不是所有“需要跨层取对象”的情况都该上 Service Locator。只有当以下条件同时满足时，才值得考虑：
- 项目是纯函数式风格，大量使用
function而非class，无法用构造器注入（如 WordPress 插件钩子回调） - 存在动态服务发现需求，比如插件系统需运行时加载第三方服务，且无法提前声明依赖
- 维护一个非常老的 PHP 5.3+ 项目，无法升级依赖注入容器，又急需解耦某几个核心服务
此时务必给 ServiceLocator 加上类型断言和注册校验：
public static function get(string $key): object {
$service = self::$services[$key] ?? null;
if (!$service) {
throw new RuntimeException("Service '$key' not registered");
}
return $service;
}
最关键的细节：永远别让 ServiceLocator 成为“万能胶水”。它不该承载数据库连接、HTTP 客户端、缓存实例这些有明确生命周期和配置的对象——这些应该由专用工厂或配置驱动的容器管理。Service Locator 只适合兜底、临时、低耦合度的轻量服务定位，比如日志门面、当前用户上下文这类弱状态对象。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
