facade会掩盖真实依赖关系，导致ide不可见、测试难mock、重构易遗漏；其静态调用实为容器单例共享状态，引发隐式副作用；且迁移时因硬编码绑定名而成为瓶颈，仅适合route、config等无状态官方门面。
Facade 会掩盖真实的依赖关系
当你在控制器里写 Log::info()、Cache::get()、Db::table() 一连串静态调用时，表面看代码很清爽，但实际隐藏了三个强依赖：日志驱动实例、缓存连接实例、数据库连接实例。这些依赖不会出现在构造函数参数里，IDE 看不到，单元测试难 mock，重构时也容易漏掉。
更麻烦的是，这些 Facade 调用都走 Container::make()，而容器默认返回单例 —— 表面是“静态调用”，背后却是共享状态。比如你在中间件里改了 Db 的查询选项，后续所有用 Db::table() 的地方都会受影响，却没有任何提示。
测试和调试时 Facade 行为不一致
在命令行（如 php artisan tinker）或单元测试中，Facade 可能根本无法工作，除非你手动启动完整应用上下文。常见报错包括：
-
Identifier "db" is not registered：容器没绑定db -
A facade root has not been set：getFacadeClass()返回空或非法标识符 -
Call to undefined method：Intelephense 或 PHPStan 静态分析直接报红，因为它们不执行__callStatic
这些问题不是代码写错了，而是 Facade 把“运行时动态代理”伪装成“静态接口”，导致开发、测试、分析工具三者看到的“契约”完全不同。
替换子系统或迁移时 Facade 成为硬编码瓶颈
Facade 的核心是 getFacadeClass() 返回一个字符串标识符，比如 return 'cache'。这个字符串必须和容器绑定名完全一致。一旦你想把本地 FileCache 换成 RedisCache，就得同时改两处：
- 容器绑定位置（如
bind('cache', RedisCache::class)） - 所有自定义 Facade 类里的
getFacadeClass()（如果写了硬编码）
更隐蔽的问题是：有些业务代码直接 use think\facade\Cache，等于把框架耦合写死了。换成 Laravel 或自研框架时，这类代码几乎没法平滑迁移 —— 它不是“用了缓存”，而是“用了 ThinkPHP 的 Cache Facade”。
真正该用 Facade 的地方其实很少
Facade 合理的使用边界非常窄：仅限框架官方提供的、职责单一、生命周期稳定、极少需要定制的门面，比如 Route、Config、Env。它们不持有状态，不涉及 I/O，也不依赖其他服务。
而像 Db、Log、Cache 这类带状态、需配置、常要 mock 的服务，更适合显式注入：
- 控制器构造函数里声明
protected $db并通过容器自动注入 - 领域服务类里用
public function __construct(ConnectionInterface $db) - 单元测试时直接传入
Mockery::mock(ConnectionInterface::class)
Facade 最容易被忽略的代价，不是它“不能用”，而是它让“哪里用了什么依赖”这件事，从代码可读变成了运行时黑盒。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
