模型中直接调用Facade会破坏依赖注入链，导致无法单元测试、mock依赖及统一管理生命周期；事务上下文丢失、多库切换失效、服务未绑定报错、租户配置失效等问题频发，本质是滥用语法糖。
Facade在模型里直接调用会破坏依赖注入链
模型（Model）本该专注数据逻辑，比如验证、关联、事件钩子；但若在模型方法里直接写 Db::table() 或 Cache::get()，就等于把容器实例的获取过程硬编码进业务类。这会导致：模型无法被独立单元测试（因为静态调用绕过了构造函数注入）、无法在测试时轻松 mock 依赖、也无法通过容器统一管理生命周期（比如连接池复用、事务上下文传递）。
事务和连接上下文丢失是高频翻车点
ThinkPHP 的数据库操作默认走当前请求的连接实例，而该实例会参与事务控制。但 Db:: 这类 Facade 调用每次都会触发 createFacade()，它从容器取的是「新解析」的实例——如果之前已开启事务，这个新实例大概率不共享同一连接句柄，导致：
-
Db::table('user')->update()在事务中执行，但没生效 - 手动
$this->db->transaction()开启的事务，被Log::info()里的Db::调用悄悄“污染”了连接状态 - 多库场景下，
Db::connect('slave')::table()写法看似可行，实则因 Facade 不支持动态标识符，getFacadeClass()返回固定字符串，根本切不到从库
getFacadeClass() 返回值写错不会报错，但运行时炸
模型里自定义 Facade（比如 app\common\facade\Payment），常有人在 getFacadeClass() 里直接返回完整类名字符串：return \app\common\service\PaymentService::class;。问题在于：这个类若没在容器中显式绑定（Container::bind() 或 Facade::bind()），createFacade() 就查不到服务标识，最终抛出 InvalidArgumentException: Identifier "app\common\service\PaymentService" is not registered.。更隐蔽的是，如果该类有不可自动解析的构造参数（如需传入第三方 SDK 实例），容器反射失败，错误信息反而被吞掉，只留空响应或 500。
模型继承链里 Facade 调用可能意外覆盖父类行为
当模型继承自 think\Model，又在自身方法里用 Config::get('database.prefix') 拼表名，看似省事。但若项目后期引入多租户，需要按租户动态切换配置，此时 Config::get() 取的是全局配置，而非当前租户上下文。而真正可控的方式是把配置项作为依赖注入进模型构造函数，或通过 $this->app->config->get()（即容器实例）来访问——后者能配合中间件提前设置租户隔离的配置实例。Facade 的静态调用在这里成了隐性技术债。
立即学习“PHP免费学习笔记（深入）”；
Facade 本质是语法糖，糖吃多了会蛀牙。模型里要不要用，关键看那行Db:: 是临时救急，还是真需要脱离当前模型实例的上下文独立运作。多数时候，它只是偷懒的借口。 
