Facade 正确解耦依赖容器绑定而非自身；需用字符串标识符绑定服务、保持方法签名一致、避免依赖泄漏、确保自动加载与标识符严格匹配。
Facade 直接绑定 Service 类会破坏解耦
不会增加耦合——但前提是正确使用。Facade 本身是门面，不是绑定目标；它只负责把静态调用转发给容器里已注册的服务实例。如果你在 getFacadeClass() 中直接返回 app\service\OrderService::class 这样的完整类名，又没在容器中显式绑定该类，就会导致两个问题：一是每次调用都 new 实例（绕过容器生命周期），二是无法替换实现（比如测试时换 MockService）。真正的解耦发生在容器绑定层，不是 Facade 层。
- 正确做法：先通过
App::bind('order_service', OrderService::class)或服务提供者绑定字符串标识符 - Facade 中
getFacadeClass()返回'order_service'，而非类名字符串 - 这样 Controller 调用
OrderFacade::createWithStockLock()时，实际执行的是容器管理的单例实例方法 - 后续想切换为
AsyncOrderService，只需改 bind 行，不碰 Facade 和控制器代码
Facade 方法名和 Service 方法签名必须严格对齐
Facade 不做任何逻辑转换，它只是代理。一旦你在 OrderService 里改了 createWithStockLock() 的参数顺序或类型提示，而 OrderFacade 没同步更新（虽然 Facade 本身没写方法体），PHP 就会在运行时报 ArgumentCountError 或类型不匹配——因为 __callStatic() 是原样透传参数的。
- Service 方法加了新必填参数？Facade 调用方（如控制器）必须同步补全，否则崩
- Service 方法从
public function createWithStockLock(array $data)改成public function createWithStockLock(OrderDTO $dto)？Facade 调用点要提前适配 DTO 构造 - 别指望 Facade 帮你做参数转换或默认值填充——它连函数签名都不校验，只管转发
Facade 不能掩盖 Service 的依赖泄漏问题
如果 OrderService 的构造函数里注入了 Request 或带 session 的 Cache 实例，那即使你用 Facade 包了一层，这个 Service 依然不是安全的单例。并发请求下可能共享状态，而 Facade 完全不感知这事——它只管把调用扔给容器返回的实例。
- Facade 看不到 Service 内部是否持有了请求上下文对象
- 这种 Service 应该设为非单例，用容器绑定策略控制作用域（如
App::bind('order_service', function () { return new OrderService(request()); })） - 或者改用工厂模式，在 Facade 的
__callStatic()里手动构建，而不是依赖容器自动解析 - 否则上线后偶发数据错乱，排查点会卡在“明明用了 Facade，怎么还串数据？”
Facade + Service 组合真正容易被忽略的点
Facade 类本身不参与自动加载注册——它只是个壳。很多人加完 app\facade\OrderFacade，忘了在 composer.json 的 psr-4 里加映射，结果 Class not found 报在 Facade 上，却去查 Service 是否写错命名空间。
立即学习“PHP免费学习笔记（深入）”；
- Facade 类路径必须被 Composer 自动加载识别，否则
OrderFacade::xxx()根本进不了__callStatic() - Service 类路径也要注册，且必须执行
composer dump-autoload（TP8 还建议补php think optimize:autoload） -
getFacadeClass()返回的字符串，必须和容器bind()的第一个参数完全一致（大小写、下划线都敏感） - 这些全是静默失败点：不报错，只是调用时返回 null 或抛出
Identifier "xxx" is not registered
