ThinkPHP的prefix仅在Db::name()和未设$table的模型中生效，显式指定$table、Db::table()、join()等均不自动加前缀；多连接需各自配置prefix，.env与config中须动态读取，调试应以dump配置和SQL日志为准。
ThinkPHP 的 prefix 配置只在连接层生效，不是全局开关
你改了 config/database.php 里的 'prefix' => 'tp_'，但某个模型还是查 user 表而不是 tp_user——大概率是因为这个模型用了 $table 显式指定全名，或者走的是另一个数据库连接配置。ThinkPHP 的前缀逻辑非常“务实”：它只在两个地方加前缀：Db::name('user') 和未设 $table 的模型查询；其他所有写法（Db::table()、原生 SQL、join()）都不自动处理。
常见错误现象包括：
-
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'db.tp_tp_user' doesn't exist—— 配了prefix却又在模型里写$table = 'tp_user'，结果拼出双重前缀 - 多连接场景下只配了
default的prefix，但代码用了Db::connect('slave')，而slave连接里没设prefix，导致关联表漏前缀
多站点共用一个数据库时，prefix 必须按站点独立配置
宝塔面板上多个 ThinkPHP 站点连同一个 MySQL 数据库，靠的就是每个站点的 prefix 不同，比如 site_a_ 和 site_b_。这不是“建议”，是硬性隔离手段——因为表物理共存，不靠前缀区分，数据就混了。
实操要点：
立即学习“PHP免费学习笔记（深入）”；
-
.env文件里分别写DB_PREFIX=site_a_和DB_PREFIX=site_b_，对应站点各自加载 -
config/database.php中必须用'prefix' => env('DB_PREFIX', 'tp_')，不能写死字符串，否则环境变量失效 - 别指望模型或中间件里动态改
prefix来切换——运行时修改连接配置不可靠，且无法影响已加载的模型类定义 - 如果某张表是跨站点共享的（如字典表），就单独建一个无前缀的表，并在查询时用
Db::table('shared_dict')显式调用，避开 prefix 机制
join() 和 table() 不走 prefix，手动拼接要小心
Db::name('article')->join('user u ON u.id = article.user_id') 这句里 user 不会自动变成 tp_user，框架只对主表做前缀处理。一旦漏掉，线上就会报错“表不存在”。
安全做法：
- 把前缀提前抽成变量：
$prefix = config('database.connections.default.prefix');，然后join($prefix . 'user u ON ...') - 用
Db::raw()包裹复杂表达式，避免字符串拼接出错：join(Db::raw(config('database.connections.default.prefix') . 'user u ON u.id = article.user_id')) - 如果 join 的是不同前缀的表（比如 A 站点查 B 站点的用户表），那就得切连接：
Db::connect('site_b')->name('user')，而不是硬拼前缀
调试时别猜，直接看生成的 SQL 或 dump 配置
你以为 prefix 生效了，其实它被覆盖、被忽略、或压根没读到。最省时间的方式是验证事实，不是检查代码逻辑。
立刻能做的几件事：
- 在控制器里加一行：
dump(config('database.connections.default.prefix'));，确认输出是你预期的字符串（比如"site_a_"），而不是空、null或默认的"tp_" - 开启调试模式，打开 trace 面板，在「SQL」栏里找真实执行语句，看表名有没有前缀——这是唯一权威依据
- 清空
runtime/下的cache/和log/，尤其是 TP5/6 的配置缓存，改了database.php不清缓存等于白改 - 注意多应用项目里，
config/database.php可能被模块级配置覆盖，检查是否误写了application/admin/database.php并覆盖了prefix
真正容易被忽略的，是迁移文件和种子数据里硬编码的表名。它们不会读取 prefix 配置，上线后一跑迁移，就可能建出没前缀的表，跟模型对不上。
