facade不能替代模型方法调用，因其绕过验证、事件、软删除等核心逻辑；适合统计、批量更新等简单查询；高频调用需复用实例；启动早期或测试中应避免使用，推荐依赖注入。
Facade 不能替代模型方法调用
当你需要复用模型层的业务逻辑（比如用户状态校验、密码加密、关联数据预加载）时，直接用 Db::table('user') 绕过模型是危险的。模型类（如 app\model\User）封装了验证规则、事件钩子、自动时间戳、软删除等行为，而 Db Facade 只提供原始查询能力，这些逻辑全部丢失。
常见错误现象：Db::table('user')->insert(['password' => '123456']) 直接写入明文密码；或 Db::table('user')->where('id', 1)->delete() 彻底物理删除，跳过软删除机制。
- 必须走模型操作的场景：创建/更新带验证的数据、触发
saving/saved事件、使用with()预加载关联、依赖模型的访问器（getFullnameAttr） - Facade 适合场景：统计类查询（
Db::table('order')->sum('amount')）、批量更新字段（Db::table('user')->where('status', 0)->update(['status' => 1])）、临时脚本导出
Facade 不适合高频调用且需复用实例的场景
Log::info() 或 Cache::get() 看似方便，但如果在单次请求中被循环调用数百次（比如遍历 1000 条订单逐条记录日志），每次静态调用都会触发 __callStatic → createFacade() → 容器解析，带来额外开销。此时应提前从容器取一次实例复用。
性能影响：PHP 8.5.5 下实测，1000 次 Log::info() 比 $log = app('log'); for (...) { $log->info(); } 慢约 12%～18%，差异来自反射和容器查找。
- 推荐做法：在控制器方法开头用
$cache = app('cache')或$db = Db::connection()获取实例，后续复用 - 特别注意：自定义 Facade 若其
getFacadeClass()返回未注册到容器的标识（如误写为'my_service'而实际绑定的是'app\common\MyService'），会抛出InvalidArgumentException: Identifier "my_service" is not registered
Facade 不适合需要精确控制依赖注入时机的场景
Facade 的本质是容器代理，它隐式依赖容器已初始化、服务已绑定。若你在框架启动早期（如 boot() 阶段）、命令行入口或单元测试 setup 中就调用 Config::get()，而此时容器尚未完成配置加载，可能返回空值或触发异常。
容易踩的坑：think\facade\Config 在 App::initialize() 之前不可靠；Env::get() 若环境变量未通过 Dotenv 加载完毕，读取结果不确定。
- 安全时机：控制器、中间件、模型方法内调用基本无风险
- 高危时机：全局函数文件（
helper.php）、服务提供者register()方法、静态属性初始化（private static $conf = Config::get('app.debug');） - 替代方案：改用
app('config')并加判空，或延迟到App::afterStart()回调中执行
Facade 不适合需要 mock 或替换实现的测试场景
单元测试中，你无法直接对 Db::table() 打桩（mock），因为它是静态门面，背后是运行时动态代理。强行 mock 静态方法需依赖扩展（如 phpunit/phpunit-mock-objects 的 staticExpects），但与 ThinkPHP 容器机制冲突，极易失效。
真实问题：写一个测试想验证“发送邮件失败时是否回滚事务”，但 Mail::send() 是 Facade，mock 后事务仍由 Db 实例控制，两者解耦失败。
- 可测性更好的写法：将业务逻辑抽成普通类，构造函数注入
think\db\Connection和think\mail\Mailer实例，测试时直接传入 mock 对象 - Facade 仅保留给“胶水层”调用——即控制器接收请求、调用业务类、返回响应这一链路的最外层
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
