TP8中Request对象不能通过注解或构造器自动注入，只能通过控制器方法参数传入或App::make('request')显式获取；非HTTP上下文调用会失败，且无作用域管理。
TP8（ThinkPHP 8）中不能像 Spring Boot 那样通过 @Autowired 或构造器参数自动注入 Request 对象——它没有运行时依赖容器的类型提示解析机制，也没有 Request Bean 的生命周期管理。你看到的“控制器方法里写 Request $request 就能用”，本质是框架在调度时**手动传参**，不是容器注入。
为什么控制器方法参数能写 Request？
ThinkPHP 8 的路由调度器（think\Route）在执行控制器方法前，会做两件事：
- 反射读取方法签名，识别出参数类型为
think\Request或其子类 - 调用
think\App::make('request')创建或复用当前请求实例，再作为实参传入
这跟 Laravel 的服务容器自动解析类似，但 TP8 的 App::make() 并不支持任意类的自动构造，只对少数核心类（如 Request、Response、View）做了硬编码适配。它不是通用 DI 容器，而是轻量级工厂 + 缓存封装。
App::make('request') 是唯一可靠方式
想在非控制器上下文（比如 Service 类、中间件、命令行指令）里拿到当前请求对象，必须显式调用：
$request = \think\App::make('request');
注意以下几点：
- 该调用仅在 HTTP 请求生命周期内有效；命令行或定时任务中调用会返回空或抛异常
- 不要在类属性上用
protected $request = \think\App::make('request');—— 属性初始化发生在类加载时，远早于请求上下文建立 - 若需在 Service 中使用，应在方法内按需获取，而非构造时保存引用
- TP8 不支持
@Inject或#[Inject]等注解注入Request
别把 input() 当 Request 注入
常见误区：在 Service 中直接调用 input('name') 或 request()->param('name')。这些是全局函数或静态代理，底层仍依赖 \think\App::make('request')，但隐藏了依赖关系，导致单元测试难 mock、逻辑耦合重。
正确做法是把 $request 作为参数传入 Service 方法：
public function handle(\think\Request $request) {
$name = $request->param('name');
// ...
}
这样既清晰表达了依赖，也方便在测试时传入模拟对象。
TP8 的 Request 获取本质上是一次性工厂调用，不是容器管理的 Bean。任何试图“注入”它的尝试，只要脱离了控制器方法参数或 App::make() 显式调用，都会失败或不可靠。最易被忽略的是：它没有作用域概念（比如 request-scoped bean），也不会随请求结束自动销毁——全靠开发者自己控制使用时机和生命周期。
