服务容器解耦的本质是手动绑定策略而非自动机制，依赖bind()、singleton()等显式注册接口与实现，反射仅在类型提示+正确绑定时生效，伪注入和未绑定抽象将导致解耦失效。
服务容器解耦的本质不是自动的，而是靠绑定策略决定的
它不自动解耦，只提供解耦所需的工具链：绑定接口、延迟解析、依赖自动注入。真正起作用的是你如何用 bind()、singleton() 或 instance() 去组织类之间的关系。
常见错误是把一个含私有状态的类（比如带 $cache = [] 的计数器）用 bind() 注册，结果所有请求共享同一份数组——这不是容器“坏了”，是你没控制好复用边界。
-
bind(EmailService::class, SendGridService::class)：接口与实现分离，换邮件服务商只需改这一行 -
singleton(Logger::class, fn() => new FileLogger('/var/log/app.log'))：全局单例，适合无状态或只读配置类 - 别在
bind()闭包里use ($config)——那个变量会被所有请求捕获并共用
Laravel 5.5 的容器已支持反射 + 闭包绑定，但必须手动触发解析
5.5 版本的 Illuminate\Container\Container 已完整支持 PHP 反射获取构造函数参数类型，并自动注入对应实例。但它不会“主动”去解耦控制器或模型；只有当你在构造函数中写 public function __construct(UserRepositoryInterface $repo)，再配合容器绑定，才会生效。
典型漏点：控制器里写了 new UserRepository()，哪怕你已经在 AppServiceProvider@register() 里绑定了接口，也完全绕过了容器，等于没解耦。
- 必须让类通过
make()或构造函数注入进入容器生命周期，否则反射和依赖注入不触发 - 5.5 不支持自动扫描类型提示并绑定——你得显式调用
$this->app->bind() - 如果依赖类没被绑定，容器会尝试用反射 new 出来，但一旦构造函数参数类型是接口，就会抛出
BindingResolutionException
解耦失败常因“伪依赖注入”：类型提示了，但没真正走容器
最隐蔽的问题是：控制器写了 __construct(EmailService $email)，看起来用了依赖注入，但 EmailService 没在容器里绑定，Laravel 5.5 会 fallback 到反射创建——此时它根本没走绑定逻辑，更谈不上解耦。
验证是否真走容器：在 EmailService 构造函数里加 throw new Exception('called')，如果请求时没抛异常，说明它被反射直接 new 了，没经过你的绑定。
- 检查
AppServiceProvider@register()是否执行（可加日志）、是否调用了bind() - 确保绑定的抽象名（第一个参数）和构造函数类型提示**完全一致**，包括命名空间——
App\Services\EmailService和EmailService是两个东西 - 别依赖“自动发现”，5.5 没 Laravel 9+ 的 auto-discovery 机制，全靠手写绑定
解耦效果取决于你是否把“变化点”推到绑定层
比如发短信服务，不同环境要用不同通道：开发用 LogSms，生产用 AliyunSms。解耦的关键不是用了容器，而是你把切换逻辑压到了绑定处：
// AppServiceProvider@register()
if (app()->environment('production')) {
$this->app->bind(SmsService::class, AliyunSms::class);
} else {
$this->app->bind(SmsService::class, LogSms::class);
}
控制器里永远只依赖 SmsService::class 接口，后续加腾讯云、华为云，都不用动业务代码。
容易被忽略的复杂点：当你要替换的实现类本身也有依赖（比如 AliyunSms 需要 Config 和 HttpClient），这些依赖必须也能被容器解析——否则绑定会失败，或者 fallback 成反射 new，导致解耦断裂。
