Service构造函数注入Request总为null，因Request依赖请求上下文而Service默认单例，导致复用过期实例；应改用方法参数传入或提取必要数据解耦。
Service 构造函数里注入 Request 为什么总是 null
因为 Request 实例在 Service 被容器创建时可能还没初始化，或者 Service 被注册为单例后，Request 实例被复用导致上下文错乱——这不是你写错了，是生命周期没对上。
ThinkPHP 容器默认把 Service 当作 singleton 管理，而 think\Request 虽然也是单例，但它内部状态（如 $this->param、$this->get、$this->post）依赖当前请求的完整解析流程。一旦 Service 在第一次请求中被实例化并缓存，后续请求再取这个 Service 实例时，它持有的 Request 对象仍是第一次的引用，但里面的参数、路由信息等早已过期。
- 构造函数注入发生在 Service 首次
make()时，此时若容器尚未执行bindRequest()（比如入口不是public/index.php），Request根本不存在，直接抛BindingResolutionException - 即使成功注入，单例 Service 持有的 Request 实例不会随新请求自动更新 ——
$request->param('id')可能返回上一个请求的值，或空 - CLI 环境下
Request初始化逻辑不同，$_SERVER缺失关键字段，param()、routeInfo()全失效，但错误不报，只默默返回 null
想在 Service 里安全用 Request，得换方式
别在构造函数里写 private Request $request，改用「按需获取 + 显式传参」更可靠。
- 把 Request 当作方法参数传入：在控制器里调用
$userService->createUser($request)，Service 方法签名写成public function createUser(Request $request)—— 这样每次都是新鲜的 Request 实例 - 用
app()->request手动取（慎用）：仅限简单场景，且必须确保调用时机在路由解析之后（比如不能在中间件beforeRoute阶段用） - 提取必要数据提前传入：比如只用
$request->param('user_id')，那就控制器里先取出来，再传$userService->createUser($userId)，彻底解耦请求上下文
为什么 $request->module() 或 $request->routeInfo() 在 Service 里返回空
这两个值不是 Request 自带的，是路由匹配完成后由 think\App 主动写进 $request->module 和 $request->routeInfo 属性的。Service 如果在路由前就初始化了，这些属性根本没被赋值。
立即学习“PHP免费学习笔记（深入）”；
-
$request->module()返回空，大概率是因为 Service 实例化早于think\middleware\ParseUrl中间件执行 -
$request->routeInfo()['domain']同理 —— 域名绑定信息只在域名路由规则匹配后才注入，不在$request->domain()里（那个只读HTTP_HOST） - 检查你的 Service 是否被放在
app/provider.php的providers数组里：如果类名进了 providers，容器会在应用启动早期就make()它，必然拿不到路由数据
最常被忽略的一点：Request 不该出现在 Service 构造函数里
Service 层职责是封装业务原子操作，不是处理请求解析。一旦构造函数依赖 Request，你就被迫把所有 Service 实例都变成 request-scoped（每次请求新建），而 ThinkPHP 默认不支持这种作用域 —— 你得自己写工厂绑定，比如：
$container->bind(UserService::class, function ($app) {
return new UserService($app->request);
});
但这只是绕过问题，没解决问题本质。真正该做的，是把请求解析逻辑上移到控制器或专门的 RequestValidator 类，Service 只接收干净、结构化的输入。否则并发下极易出现状态污染，而且没法单元测试。
