根本原因在于配置项prefix只对db::name()有效，对模型类完全无效；模型默认使用完整表名，需在模型中显式设置$table或重写gettablename()方法。
ThinkPHP数据库前缀配置不生效，**根本原因在于：配置项 prefix 只对 Db::name() 有效，对模型类（Model 或继承 think\Model 的类）完全无效**。这不是 Bug，是 TP6+ 的明确设计——模型默认使用「完整表名」，不会自动拼接前缀。
Db::name() 能加前缀，但模型类不能
这是最常被混淆的点。你配了 'prefix' => 'tp_'，然后写：
-
Db::name('user')->select()→ 实际查tp_user（✅ 正确生效） -
UserModel::where('id', 1)->find()→ 实际查user（❌ 不加前缀，哪怕数据库里只有tp_user）
一旦真实表名是 tp_user，而模型没声明前缀，就会报错：Base table or view not found: 1146 Table 'xxx.user' doesn't exist。这不是连接失败，是 SQL 里表名写错了。
模型中手动加前缀的三种方式（选一个用）
别指望配置“自动生效”，模型必须显式告诉框架该查哪个表：
- 最简单：在模型类里直接写死完整表名 ——
protected $table = 'tp_user'; - 想动态读配置：重写
getTableName()方法（TP6 推荐，比改__construct更安全）：public function getTableName(): string { return config('database.connections.mysql.prefix') . 'user'; } - 如果用了多数据库连接（如
'slave'），注意前缀取的是对应连接的配置，不是全局的database.php顶层prefix；若连接配置里没定义prefix，才会 fallback 到全局值。
为什么 Db::name() 生效，而 Model 不生效？
底层逻辑完全不同：
-
Db::name('user')走的是查询构建器路径，会主动调用parseTable()去读prefix配置并拼接 - 模型类的
$table属性是直接参与 SQL 构建的字符串，框架不做任何额外处理 —— 这是为兼容历史行为和避免隐式副作用做的取舍 - 开启
deploy模式（'deploy' => 1）后更危险：它会绕过$table和前缀配置，强行从模型名推导表名（比如UserModel→user），导致 prefix 彻底失效
验证前缀是否真的加载成功
别只看配置文件有没有写，要实测运行时值：
- 在控制器里加一句：
dump(Db::name('user')->getRealTableName());→ 应输出tp_user，否则说明prefix没读到或为空字符串 - 检查
.env文件是否在项目根目录、APP_DEBUG=true是否开启（否则环境变量不加载） - 确认
config/database.php中'prefix'是字符串类型，且末尾无空格（Windows 下空格不易察觉但会导致拼接成tp_ user）
最容易被忽略的是：你以为模型应该“继承” Db 的前缀逻辑，其实它俩压根走不同通道；只要模型没显式指定表名，就永远按你写的字面量去查 —— 这个事实比任何配置都硬。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
