ThinkPHP接口模型怎么定_ThinkPHP模型接口汇总【教程】

先说几个核心判断：ThinkPHP 接口开发中的模型，并不是为接口单独设计的组件，而是整个数据操作的统一出口。只要模型定义干净、关联清晰、字段可控，控制器里直接写 UserModel::get(1) 或 UserModel::where('status', 1)->select()，返回的就是结构化数据，完全不需要再额外封装一层。很多接口慢、字段乱、报错找不到模型，根子都在 app/model/ 下那个 PHP 文件没写对。

模型文件位置和命名必须严格匹配表名与 PSR-4 规范

模型类名决定了它默认关联哪张表——User 类对应 user 表（带前缀则为 tp_user），UserProfile 对应 tp_user_profile。路径必须是 app/model/User.php，命名空间必须为 app\model。这里常见的坑有两个：

• 文件名小写（app/model/user.php）或命名空间大小写不对（App\Model\User）——自动加载直接失败。
• 表名本身含大写字母，比如 userLog？那必须显式写 protected $table = 'user_log';，否则框架猜不到。
• 主键不是默认的 id？加一行 protected $pk = 'uid';，不然 get($id) 查不出数据。

protected $table 和 $tableName 的区别别搞混

这两个属性名字相近但含义不同：$table 是完整表名（含前缀），$tableName 是不带前缀的表名，框架优先认 $table。如果两个都设置，$table 说了算。

• 想让 User 模型查 members 表（无前缀）：用 protected $table = 'members';。
• 想让 User 查 tp_users 表（有前缀但类名不匹配）：用 protected $tableName = 'users';，前缀仍走 database.php 配置。
• 动态切换数据库？千万别动 $connection 属性——接口高频场景下容易引发连接复用混乱。更稳妥的做法是用 Db::connect($config)->name('user')->select()，临时切换，不污染模型。

API 场景下模型字段要主动控制，别依赖 select *

接口返回全字段，不仅响应慢，还可能把 password、salt、is_deleted 这些敏感字段暴露出去。模型里直接加两行配置最省心：

• protected $hidden = ['password', 'salt']; 隐藏指定字段。
• 或者用 protected $visible = ['id', 'name', 'email']; 只显示白名单字段。注意 $hidden 和 $visible 互斥，同时设的话以 $visible 为准。
• 时间字段想自动转格式？加 protected $type = ['create_time' => 'datetime:Y-m-d H:i:s']; 就能在 JSON 输出时直接拿到格式化时间。
• 如果需要返回驼峰命名字段，模型里不用处理，交给控制器：json($user->toArray(), 200, [], ['convert_keys' => true])。

关联模型在 API 中怎么用才不拖慢响应

一对多查用户订单，直接写 $user->orders 确实简洁，但默认是懒加载——每次访问才查询，控制器里多次调用就会产生 N+1 问题。接口必须预载。

• 查单个用户及其订单：UserModel::with('orders')->find($id)。
• 查多个用户并预载头像，还能只取关键字段：UserModel::with(['a vatar' => function ($q) { $q->field('id, url'); }])->select()。
• 关联定义本身要写清楚：public function orders() { return $this->hasMany(Order::class, 'user_id'); }。漏掉第二个参数（外键），框架就不知道按哪个字段关联，查错表是常有的事。

总结一下：模型本身不区分“接口模型”还是“页面模型”，关键看定义够不够干净、字段有没有收敛、关联是不是预载了。把这些基础写扎实，接口性能自然就上去了。