ThinkPHP模型找不到怎么修_ThinkPHP模型路径配置指南【汇总】

模型类找不到，这事儿在 ThinkPHP 开发里太常见了。说到底，绝大多数情况都不是你代码写错了，而是命名空间、文件路径、数据库配置这三者之间没有对齐——框架在 PSR-4 规则下，压根认不出你把类文件扔在了哪个角落。

Class 'app\model\User' not found：命名空间和目录结构不匹配

ThinkPHP 6 对命名空间的检查相当严格，要求命名空间和磁盘路径必须一一对应。举个例子，如果文件放在 app/model/User.php，那命名空间就应该是 namespace app\model;，不能写成 App\Model（首字母大写），也不能是 app/model/（末尾带斜杠），更不能是 app\model（反斜杠写错位置）。另外，Linux 环境下文件名大小写敏感，User.php 和 user.php 是两个完全不同的文件。这一点在 Windows 本地开发时往往没问题，但一上线部署就立刻报错。

• 先检查 composer.json 中 "autoload": {"psr-4": {"app\\": "app/"}} 是否还在，是否被意外注释了。
• 任何文件位置或命名空间的改动，都需要运行 composer dump-autoload -o 重新生成类映射。
• 可以用 php -r "var_dump(class_exists('app\model\User'));" 快速验证类是否能被自动加载到。

M('User') 或 D('User') 报 404 或 Fatal error：模型实例化时连不上数据库

如果是 ThinkPHP 3.x 的老项目，还习惯用 M() 或 D() 方法实例化模型，那就要格外小心了——这两个方法在初始化时会尝试连接数据库并检查对应数据表是否存在。一旦数据库配置有问题，比如账号密码填错、用户权限不足，或者模型对应的数据表不存在（比如 User 模型默认查 user 表），就会直接中断加载，报出 404 或 require_once(): Failed opening required 这类错误。

• 先确认 config/database.php 中的 hostname、username、password、database 是否全部填写正确，并且该数据库用户至少拥有 SELECT 权限。
• 临时注释掉模型里的 protected $table = 'xxx';，或者删除 __construct() 中手动连接数据库的代码，排除干扰项。
• 用 php think migrate:status 或者直接 mysql -u xxx -p -e "USE your_db; SHOW TABLES;" 验证目标数据表是否真实存在。

模板里用 {$user->name} 报错：模型类加载成功但属性访问失败

如果模型类本身找到了，但模板里访问数据时报错，那问题多半出在数据读取环节。常见原因有两个：数据库字段名与模型属性名不一致，或者开启了严格字段检查（'fields_strict' => true）。

• 检查模型是否定义了 protected $name = 'user'; 来明确指定真实表名，避免框架按类名小写自动推导时出错。
• 确认数据库字段是 user_name 还是 name。如果字段带下划线，可以尝试关闭 'auto_write_timestamp' => false 和 'pk_convert' => true，看是否能缓解。
• 在控制器里输出 dump($user->toArray());，查看返回的是空数组还是所有字段全为 null——这能帮你快速判断是模型映射问题还是数据库查询本身出了问题。

升级到 ThinkPHP 6 后模型全部失效

TP6 的改动确实不小，彻底移除了对 Common/Model 和 Lib/Model 等旧路径的支持。所有模型必须统一放在 app/model/ 下，并且必须继承 think\Model，不能再像以前那样写 class User {} 或 Think\Model 了。

• 把旧模型从 Lib/Model/UserModel.class.php 迁移到 app/model/User.php。
• 头部必须声明 namespace app\model;，并 use think\Model;，然后 class User extends Model。
• TP6 不再识别 .class.php 后缀，文件名直接就是 User.php，不是 UserModel.php（除非你显式定义了 protected $name = 'user_model';）。

最后，最容易被忽视的一点是——缓存没清。哪怕路径和命名都正确无误，runtime/cache/ 和 runtime/container/ 里残留的旧类映射也会让框架继续找错地方。遇到这种问题，删掉整个 runtime/ 目录重新再试，往往比反复改配置要快得多。