Facade本质是静态代理而非依赖注入，它通过静态调用+容器懒加载实现，不参与类型解析与生命周期管理，无法Mock且难替换实现；依赖注入则需容器实例化、支持接口抽象与可测试性。
Facade 本质是静态代理，不是依赖注入
Facade 看起来像依赖注入，比如 Route::rule() 或 Cache::get()，但它底层走的是静态调用 + 容器代理，不经过构造函数或方法参数的类型解析。它和依赖注入共享同一个容器，但触发机制、生命周期管理、可测试性完全不同。
依赖注入必须走容器实例化流程，Facade 不需要
依赖注入生效的前提是：类必须由容器创建（app()->make() 或路由自动解析），且构造函数/方法参数有明确类型提示。而 Facade 可以在任意地方直接调用，哪怕当前上下文根本没有容器初始化（比如命令行脚本早期阶段），只要 think\facade\Facade 基类存在就能跑——但这会掩盖真实依赖，导致单元测试时无法 Mock。
- 控制器里写
public function index(UserService $service)→ 路由层通过反射调用容器，注入成功 - 控制器里写
use think\facade\Cache; Cache::get('key');→ 静态调用，容器只在第一次被懒加载，$service参数根本没参与 - 如果你在
__construct()里混用 Facade 和 DI（比如Cache::get()+UserService $service），$service可能为null，因为 ThinkPHP 默认不用容器实例化控制器
接口解耦只能靠依赖注入，Facade 绑定的是具体类
你想替换缓存驱动？用依赖注入可以绑定 CacheInterface 到 RedisCache，所有接受该接口的构造函数自动切换实现；而 think\facade\Cache 固定代理 think\Cache 类，改配置都绕不开它内部的驱动选择逻辑。Facade 的 getFacadeClass() 返回值是硬编码字符串或固定类名，没法动态换实现。
- 支持接口注入：必须用依赖注入 +
app/provider.php显式绑定，例如'app\cache\CacheInterface' => 'app\cache\RedisCache' - Facade 换实现只能改源码或重写
getFacadeClass()，且所有调用点同步改use语句 - 测试时，DI 可以传入 Mock 对象；Facade 必须 patch 静态方法或用更重的工具（如 AspectMock）
什么时候该选 Facade，什么时候必须用依赖注入
Facade 适合工具类、无状态辅助操作（日志、缓存读写、路由注册）；依赖注入适合业务核心对象（服务类、仓储、策略），尤其是需要生命周期控制、接口抽象、多环境替换的场景。
立即学习“PHP免费学习笔记（深入）”；
- 写中间件、事件监听器、命令行指令时，用 Facade 更轻量，避免每个类都写一堆构造函数参数
- 写
UserRegisterService这类含业务逻辑、要测边界条件、可能对接不同短信网关的类，必须用依赖注入 + 接口约束 - 别在 Facade 里做耗时操作（比如
Db::table()->select()），它无法被容器拦截做连接池、事务代理等增强 - 如果团队有人把
DbFacade 当成“全局数据库单例”到处用，后续想切分读写分离或加查询日志，就得全项目 grep 替换
use think\facade\Cache 就等于“用了依赖注入”，结果发现没法单元测试、换缓存驱动要改二十个文件、上线后才发现某个服务类的 $cache 属性始终是 null。 
