Facade 调用必须先将 Service 类绑定到容器并使 getFacadeClass() 返回对应标识符，否则抛出“Identifier not registered”错误；Facade 本质是 Container::make() 代理，依赖容器管理生命周期与注入。
Service 类不能直接被 Facade 静态调用，必须先绑定到容器并配置正确的 getFacadeClass() 返回值，否则会抛出 Identifier "xxx" is not registered 错误。
Service 类必须显式绑定到容器才能被 Facade 调用
Facade 本身不创建实例，它只是代理调用容器中已注册的服务。如果你写了一个 app\service\UserService，但没告诉容器“user 这个标识符对应它”，User::getInfo() 就会失败。
- 推荐方式：在
app/provider.php或服务提供者中调用Container::getInstance()->bind('user', UserService::class) - 快捷方式（仅限简单类）：在 Facade 子类的
getFacadeClass()中直接返回类名字符串，如return 'app\service\UserService'，前提是该类无构造参数或参数可被容器自动解析 - 错误做法：返回完整类名常量（如
\app\service\UserService::class）却不注册——这会让createFacade()查不到服务
getFacadeClass() 返回值不是类名，而是容器标识符
这是最容易踩坑的地方。比如你绑定了 Container::bind('user_service', UserService::class)，那 Facade 里就必须写 return 'user_service'，而不是 'app\service\UserService' 或 \app\service\UserService::class。
客服回复模板。售前咨询、售后处理、退换货、投诉回复、好评引导、升级处理、行业FAQ、满意度挽回。Customer service reply templates for pre-sale, after-sale, returns, complaints, escalation, FAQ generation, s...
- 常见标识符命名习惯：
user、order、payment，短小、语义清晰、与业务强相关 - 如果返回值拼错（如多一个空格、大小写不符），
createFacade()会静默失败，最终触发InvalidArgumentException - 调试技巧：在
think\Facade::__callStatic()里加日志，看传入的标识符是否和bind()时一致
Facade 调用本质是 Container::make()，不是 new 实例
这意味着 Service 类的生命周期、依赖注入、单例控制全由容器接管。例如你的 UserService 构造函数依赖 CacheInterface 和 Db，只要它们已在容器中注册，Facade 调用时就会自动注入。
立即学习“PHP免费学习笔记（深入）”；
- 优势：避免手动 new + 传参，解耦更彻底；支持 AOP、装饰器、运行时替换实现
- 注意点：若 Service 类有非可选构造参数且未在容器注册对应接口，
make()会报ReflectionException - 性能影响：首次调用有反射开销，但后续走容器单例缓存，基本无感知
不要在 Service 类里写静态方法再用 Facade 包一层
有人为图省事，在 UserService 里定义 public static function getInstance()，再让 Facade 去调它——这完全违背 Facade 设计初衷。Facade 的价值在于统一入口 + 容器治理，绕过容器就等于放弃依赖注入、AOP、测试替身等所有现代 PHP 特性。
- 正确姿势：Service 只写普通方法，专注业务逻辑；Facade 只负责声明“谁来干活”
- 混淆信号：如果发现自己的 Facade 类里开始补
__callStatic()以外的逻辑，说明职责已经越界 - 复杂点在于：多人协作时容易忽略绑定步骤，上线后才暴露
Identifier not registered——建议把绑定逻辑收口到 provider.php，并加单元测试验证绑定存在
