Repository在ThinkPHP中非必需，90%项目宜将复杂查询封装至Model静态方法或作用域；仅当出现多数据源、查询逻辑分支侵入Model、跨模块查法无法统一、单元测试需mock多重依赖时，才应抽离为独立类。
ThinkPHP 本身不内置 Repository 模式，强行套用反而会让代码更难维护——关键不是“有没有”，而是“值不值得拆”。
Repository 在 ThinkPHP 里到底该不该写成独立类？
很多人一看到“分层”就立刻新建 app/repository 目录、写一堆 UserRepository 类，结果发现：查询逻辑没变少，调试时要跳 4 个文件，where 条件还在 Repository 里硬拼数组。
- ThinkPHP 的
Model已经封装了查询构造器（Db、Query），本身就有“数据访问隔离”能力 - 真正需要 Repository 的场景，是存在多数据源（比如 MySQL + Elasticsearch + 缓存联合查询）、或业务规则强依赖数据获取方式（如用户信息要从 LDAP 同步后再查本地库）
- 90% 的项目，把复杂查询逻辑提到
Model的静态方法或作用域（scope）里，比单独建 Repository 更轻、更易测
什么时候必须抽离 Repository？看这三个信号
不是按“设计模式清单”来决定，而是看实际协作和演进卡点：
-
Model方法里出现if ($source === 'cache') { ... } else if ($source === 'api') { ... }这类分支——说明数据来源逻辑已侵入业务模型 - 同一个实体（如
Order）在不同模块里查法完全不同（管理后台要连 5 张表，小程序只要 status+amount），且无法用with或join统一抽象 - 单元测试时发现，光 mock 一个
Db::name('user')不够，还得 mock Redis、HTTP 客户端、甚至 Excel 导入解析器——这时才需要接口 + 实现分离
如果真要实现，别碰 TP 的 Model 继承链
直接让 Repository 持有 Db 或 Model 实例，而不是继承它们：
立即学习“PHP免费学习笔记（深入）”；
class UserRepository
{
protected $model;
public function __construct(UserModel $model)
{
$this->model = $model;
}
public function findActiveByTag(string $tag)
{
return $this->model->where('status', 1)
->whereLike('tags', "%{$tag}%")
->select();
}
}
- 不要让
UserRepository继承UserModel—— 这会模糊“操作数据”和“代表数据”的边界 - 避免在 Repository 里调用
$this->model->hidden(['password'])这类视图相关逻辑，那是Resource或 DTO 的事 - 如果用了依赖注入容器（
Container），注册时明确绑定接口：bind(UserRepositoryInterface::class, UserRepository::class)，而不是直接 new
Repository 最容易被忽略的点，是它根本不是“为了解耦而解耦”，而是为了把“怎么拿数据”这个决策，从 Service 层里拎出来——一旦你发现 Service 方法开头总要判断“这次走缓存还是 DB”，那就该动了；否则，写个清晰的 UserModel::withOrders() 更省事。
