Service层不能直接调用Db::table()，因它违反单一职责原则，导致数据访问逻辑泄漏、难以测试复用、无法DI/mock，且事务与多库管理失控；正确做法是通过Repository或Model封装数据访问。
Service 层不能直接调用 Db::table()，必须通过 Repository 或 Model 封装后间接使用。
为什么 Service 里写 Db::table() 是错的
Service 层职责是编排业务逻辑，不是拼 SQL 或管理连接。一旦你在 app\service\UserService.php 里看到 Db::table('user')->where(...)->find()，说明数据访问逻辑泄漏到了业务层——后续换数据库、加缓存、补日志、改分页方式，都得动 Service，测试也得重写。
更严重的是：这种写法让 Service 无法被单元测试（它强依赖全局 Db 实例），也无法复用（比如切换到 Redis 用户缓存时，你得重写所有 Db 调用）。
- Db 是 Facade，本质是容器代理，
Db::table()每次都走默认连接，无法隔离租户或日志库 - Service 方法若含 Db 调用，就违反了“单一职责”——它既做决策，又做取数
- TP5.1+ 的容器自动注入机制，对裸 Db 调用无感知，DI 和 mock 都失效
正确调用路径：Service → Repository → Db
Repository 是数据访问的门面，只负责单表 CRUD 或基础关联，不包含 if/else 业务判断。它把 Db::table() 封装成语义化方法，例如 findById()、findByEmail()，返回标准 DTO 或数组。
立即学习“PHP免费学习笔记（深入）”；
示例：app\common\repository\UserRepository.php
namespace app\common\repository;
use think\Db;
class UserRepository
{
public function findById(int $id): ?array
{
return Db::name('user')->where('id', $id)->find();
}
}
Service 中通过构造函数注入 Repository 实例（非 new，避免硬耦合）：
- 在
app\service\UserService.php构造函数里声明private UserRepository $userRepository; - TP 容器会自动解析并注入（前提是 Repository 已注册为服务或可自动解析）
- 调用时只写
$this->userRepository->findById($id)，完全不出现Db字样
Model 替代方案：仅限简单场景
如果项目没建 Repository 目录，且业务足够轻量，可用 Model 代替，但必须满足两个前提：
- Model 类（如
UserModel）不写任何业务逻辑，只定义$table、$pk、protected $connection = 'mysql2'等静态配置 - Service 中不 new Model，而是通过容器获取：
app()->make(UserModel::class)->find($id)，确保可被替换或 mock
注意：M('User') 和 new Model('User') 是 TP5.0 时代的写法，TP5.1+ 不推荐，它们绕过容器、无法 DI、连接不可控。
容易踩的坑：事务、连接、多库混用
Service 方法常需跨多个数据操作，此时事务和连接一致性极易出错：
- 不要在 Service 里调
Db::startTrans()—— 事务边界应由 Controller 或 Command 层控制 - 若需多库（如主库查用户、日志库写行为），Repository 必须各自持有独立
Db::connect('log')实例，不能共用Db::table() - 别在 Service 构造函数里调
Db::connect()并赋值给属性——连接对象不能复用，每次查询应新建或从连接池取 - TP6+ 支持
$this->db注入，但前提是模型或 Repository 显式声明protected $connection并匹配 config/database.php 中的键名
最常被忽略的一点：Repository 方法返回值必须统一（如总是数组或 DTO），不能有的返回 Collection、有的返回 stdClass，否则 Service 处理分支会失控。
