tp5.1升级至tp8.0后，db::name()已被彻底移除，必须全部替换为db::table()或模型调用；db::table()不自动拼接前缀，需显式写全表名或手动拼接，且不支持模型访问器、事件等，复杂业务应优先使用模型。
TP5.1 升级到 TP8.0 后，Db::name() 会直接报错或静默失效，不是配置能绕过的——它已被彻底移除，必须全部替换为 Db::table() 或模型调用。
Db::name() → Db::table() 的硬性替换规则
TP8 中 Db::name('user') 已不存在，调用即抛出 Fatal error: Uncaught Error: Call to undefined method think\db\Query::name()。这不是兼容层问题，是 Query 类本身删掉了该方法。
- 所有
Db::name('xxx')必须改为Db::table('xxx')，且不能混用（例如Db::name('user')->where(...)改成Db::table('user')->where(...)） - 若原逻辑依赖表前缀自动拼接（如
$prefix . 'user'），需确认config/database.php中'prefix' => 'think_'是否生效——Db::table()不再读取该配置，必须显式写全名或手动拼接 -
Db::table()返回的是原始查询对象，不支持模型级的访问器、修改器、事件钩子，仅适合简单 CRUD；复杂业务请优先走模型
模型调用替代 Db::name() 的正确姿势
TP8 强推模型驱动，Db::name() 的语义（“操作某张表”）应映射为“操作某个模型实例”，否则容易遗漏类型转换、验证、事件等关键环节。
- 确保模型类存在且命名空间正确：如
app\model\User对应app/model/User.php，类名首字母大写，文件名严格一致 - 模型内必须声明
protected $name = 'user';，否则User::where(...)->find()会查user表而非users表（即使数据库里是users） - 主键类型必须显式声明：
protected $pkType = 'int';或'string'，否则User::find(1)可能返回 null 且无提示 - 批量操作优先用静态方法：
User::insert([...])、User::update([...])，避免 new + save 的循环开销
路由与控制器中遗留 name() 调用的排查盲区
除了显式的 Db::name()，还有三类容易被忽略的“隐性 name()”调用，升级后会静默失败：
- 旧版中间件里调用
Db::name()（如权限校验查菜单表），升级后中间件 handle 签名也变了，必须同步补全第三个参数$params - 行为（behavior）扩展中的
Db::name()—— TP8 彻底废弃 behavior 机制，这类代码必须迁出，改用事件触发（Event::trigger('user_login')）或中间件重写 - 第三方插件或自定义基类里封装的
db()->name()别名方法，需全局搜索->name(和name\(，逐个定位替换
最危险的情况是：你改完了所有明面上的 Db::name()，但某个角落的中间件或事件监听器仍在用它，而 TP8 不报错、不提示、只返回空结果——这种静默失效比报错更难排查，务必跑通登录、列表、详情、提交四类核心链路，并检查 runtime/log/ 下是否还有未捕获的异常堆栈。
