Service层不能直接依赖Request对象，因其强绑定HTTP上下文、不可测试、违反单一职责且多进程下易出错；应显式传入所需字段或DTO，文件上传须传think\File实例。
Service层为什么不能直接依赖Request对象
ThinkPHP的Request对象是HTTP上下文强绑定的，它内部持有$_GET、$_POST、上传文件句柄、路由参数等，生命周期只在当前请求内有效。如果在Service类中直接通过容器注入或app('request')获取，会导致：Service无法单元测试（依赖全局状态）、违反单一职责（业务逻辑不该感知HTTP细节）、多进程/队列场景下可能读到错误请求数据。
推荐做法：把需要的数据显式传入Service方法
不是传Request对象本身，而是提取出Service真正需要的字段，用数组或DTO（数据传输对象）封装后传入。这样Service干净、可测、复用性高。
- 控制器里用
$request->param()、$request->post()、$request->file()等明确取值，再传给Service - 避免用
$request->all()一股脑塞过去——Service会隐式依赖未声明的字段，后续加参数易出错 - 文件上传必须用
$request->file('xxx')拿到think\File实例，再传给Service；不要传路径字符串，否则丢失原始文件名、类型等元信息
示例：
// 控制器
public function store()
{
$data = $this->request->only(['title', 'content', 'status']);
$file = $this->request->file('avatar');
$result = $this->userService->createUser($data, $file);
return json($result);
}
// Service
public function createUser(array $data, ?\think\File $file = null)
{
// 业务逻辑处理 $data 和 $file
}
需要频繁访问请求上下文时怎么办
极少数场景（如通用日志记录、权限校验中间件后的上下文增强），Service确实需要知道当前用户ID、客户端IP、请求来源等。这时建议：
service-qa-coach
下载
评估聊天、邮件、电话、社交平台私信（DM）或电商平台客服团队的服务质量。适用于团队需要制定 QA 评分卡、故障模式分析、辅导计划、校准检查清单或服务改进简报，但无法访问实时工单系统、CRM 或联络中心系统的情况。
立即学习“PHP免费学习笔记（深入）”；
- 在控制器或AOP拦截层，从
$request中提取这些稳定字段（如$request->ip()、$this->auth->id()），作为独立参数传入 - 避免在Service里调用
app('request')或input()等全局辅助函数——它们会绕过依赖声明，让调用关系不可见 - 如果项目已大量存在
Request注入，可用适配器模式包装一层，例如RequestContext接口，由控制器实现并传入，Service只依赖接口
别踩的坑：用static方法或单例缓存Request
有人会写Service::setRequest($request)然后在静态方法里用，或者在构造函数里保存$this->request = app('request')。这两种方式都错：
- 静态绑定会让Service在FPM子进程间共享同一个
Request，下次请求进来就脏了 - 构造器里用
app('request')看似“自动注入”，实则每次Service被容器解析时都会重新取一次——但如果你手动new Service()，就拿不到，行为不一致 - ThinkPHP 6.1+ 的容器默认是每次解析都新建实例，所以构造器注入
Request等于每次请求都偷偷绑了一次，看似能用，实则掩盖了设计问题
真正需要解耦的点，从来不是“怎么把Request塞进去”，而是“Service到底需要什么数据”。把这个问题想清楚，传参就自然了。
