think\facade\Db 是 TP6 正确门面类，首字母大写、命名空间严格为 think\facade\；think\Facade\Db 不存在，属常见误写；自定义门面须继承 think\Facade 并实现 getFacadeClass()。
think\facade\Db 和 think\Facade\Db 是两个不同东西
前者是门面类（Facade class），后者根本不存在。TP6 的门面类全部位于 think\facade\ 命名空间下，首字母大写，如 think\facade\Db、think\facade\Cache；而 think\Facade（F 大写但后面不是小写 facade）是框架底层抽象基类，它本身不提供任何业务方法，只定义了 __callStatic() 和 getFacadeClass()。
常见错误现象：
- 误写
use think\Facade\Db;→ 报错Class "think\Facade\Db" not found - 在 IDE 里点进
Db::table()却跳转到think\Facade基类 → 这是正常的，因为实际逻辑不在这里，而在容器绑定的实例中
Facade 类名必须首字母大写，且命名空间严格固定
所有官方门面类都遵循 think\facade\Xxx 格式，Xxx 首字母大写（StudlyCaps），不能写成 db、DB 或 Db（单独小写 D）——后者虽可能因自动加载机制“碰巧”不报错，但属于未定义行为，PHP 8.5+ 下会触发 Deprecated: Non-static method called statically 警告（如果该类没正确继承 think\Facade）。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 始终用
use think\facade\Db;，而非use think\Facade\Db;或use think\facade\db; - 自定义门面类也必须继承
think\Facade，并实现getFacadeClass()，返回容器标识符（如'my_service'），不是类名字符串 - 别依赖“大小写不敏感”自动加载 —— Windows 开发环境可能容忍
db.php被当成Db.php加载，Linux 下直接class not found
Db::table() 这种调用不区分方法名大小写，但前提是类存在且正确继承 Facade
TP6 中，只要 think\facade\Db 类存在且正确继承 think\Facade，那么 Db::table()、Db::TABLE()、Db::Table() 在 PHP 7.4+ 上都能运行（PHP 自身对方法调用不区分大小写）。但这只是语言层特性，不是框架设计意图。
为什么不该这么用：
-
Db::TABLE()会让 IDE 无法识别方法签名，失去自动补全和类型提示 - 团队协作时增加理解成本，违反 PSR-4 和 TP 官方控制器/模型的驼峰命名惯例
- 若未来某次升级收紧反射检查（如 PHP 9+），可能直接报错
容易被忽略的关键点：Facade 不是静态工具类，它的大小写容错来自 PHP 引擎，不是框架逻辑
很多人以为 Db::table() 能小写调用是因为 ThinkPHP “支持大小写不敏感”，其实完全相反：这是 PHP 解析器对方法名的宽松处理，框架本身没有任何适配代码。一旦你写的门面类没继承 think\Facade，或者 getFacadeClass() 返回了错误标识符，大小写怎么写都没用，直接抛 InvalidArgumentException: Identifier "xxx" is not registered。
真正决定能否调用成功的，只有两件事：
-
think\facade\Db类是否真实存在且可自动加载 - 容器中是否已绑定
'db'这个标识符（由框架启动时完成）
