facade仅适合封装已注册容器、无状态、职责清晰的对外服务类，如支付网关；不适合封装依赖请求上下文、会话或需链式调用的逻辑。
Facade 适合封装「有明确服务边界」的业务类
Facade 不是万能胶，它只适合包装那些本身已通过容器管理、具备清晰职责、且不依赖运行时上下文的业务类。比如支付网关、短信服务、文件上传适配器这类“对外提供统一能力”的组件。
- 必须已注册进容器（
Container::getInstance()->bind()或app()->bind()），否则createFacade()找不到实例 - 类不能强依赖
$request、$response等每次请求才有的对象；Facade 静态调用无法自动注入这些 - 方法最好是无状态或仅依赖配置（如
config('sms.driver')），避免在getFacadeClass()返回的类里做初始化耗时操作 - 不适合封装控制器逻辑、视图渲染器、或需要 session/cookie 的会话敏感操作
例如：你写了一个 app\Services\WechatPayService，它只接收订单参数、调用 SDK、返回预支付结果——这就很适合配一个 app\Facade\WechatPay，然后在任意地方用 WechatPay::unifiedOrder($order) 调用。
不适合用 Facade 封装的三类方法
有些方法看似“方便”，但硬套 Facade 反而埋坑：
- 依赖当前用户身份的方法，比如
getCurrentUserOrders()：Facade 无法自动感知登录态，必须手动传$userId，反而比直接app(UserOrderService::class)->list($userId)更绕 - 需要链式调用并中途修改状态的方法，比如
FileUploader::disk('oss')->path('tmp/')->upload($file)：Facade 代理的是单次方法调用，不维护中间状态，disk()返回的对象不是 Facade 实例，后续调用会失效 - 含有大量可选参数或行为开关的方法，比如
notify($to, $template, $channel = 'sms', $retry = true, $delay = 0)：Facade 调用虽简洁，但参数膨胀后可读性下降，不如定义明确接口（如Notification::viaSms()->delay(30)->send($to, $template)）更直观
常见错误现象：Call to undefined method app\Facade\MyService::doSomething()，往往是因为 getFacadeClass() 返回了错误标识，或者该类根本没绑定进容器。
Facade + 服务类组合的推荐写法
真正好用的 Facade 封装，一定是“Facade 类极薄、业务逻辑全在服务类里”：
-
app\Facade\Sms只负责继承think\Facade并返回'sms_service' -
app\Services\SmsService实现具体发送逻辑，构造函数里注入配置、HTTP 客户端、日志等依赖 - 在
app\common.php或服务提供者中绑定：app()->bind('sms_service', SmsService::class) - 可选：用
Facade::bind('app\Facade\Sms', 'sms_service')显式关联，避免依赖getFacadeClass()
这样既保留 Facade 的调用便利性，又不牺牲测试性——单元测试时可直接 new SmsService，Mock 其依赖；Facade 层几乎不用测。
Facade 的价值不在“看起来像静态”，而在“把服务发现逻辑收口”。一旦开始在 Facade 类里写 if-else、拼接 URL、处理异常，就说明它已经越界了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
