request对象在route::check()成功匹配路由后才真正初始化完成，此时param()、get()等方法才可靠可用；此前仅为解析$_server的“半成品”，不可依赖input()或$this->request。
Request 对象不是从入口就全程可用的，它在路由匹配成功后才真正初始化完成；在此之前调用 input()、param() 或控制器方法里的 $this->request 都可能返回空或报错。
Request 对象什么时候真正可用？
ThinkPHP 的 Request 实例分两个阶段存在：
- 入口后立即创建一个基础
Request（比如在全局中间件里能拿到app('request')），但它只解析了原始服务器变量（$_SERVER）、未处理 PATH_INFO、没绑定路由参数，param()和get()返回空是正常现象； - 只有
Route::check()成功返回Dispatch对象后，框架才会用路由解析结果重新初始化一次Request，此时param()、route()、isAjax()等方法才真正可靠。
换句话说：路由前的 Request 是“半成品”，路由后的才是“完整体”。别在全局中间件里依赖 param('id') —— 改用 $request->server('PATH_INFO') 手动提取路径再正则匹配。
为什么在全局中间件里 input() 拿不到 POST 数据？
因为 input() 底层依赖的是已解析的请求体（$this->data），而该数据是在路由调度控制器时、由 think\Controller 构造器触发的 initRequestData() 才加载的。全局中间件执行时这个动作还没发生。
- POST 数据实际在
Request::createFromGlobals()里已读入内存，但未解包到$this->post属性； - 想提前取 POST 内容，直接读原始流：
file_get_contents('php://input')，再json_decode()或parse_str()； - GET 参数倒是可以用
$request->server('QUERY_STRING')提前拿，因为它不依赖路由。
控制器里 $this->request 为空或报错？
这通常发生在闭包路由或手动 new Controller 的场景下。ThinkPHP 的控制器基类 think\Controller 默认通过构造器注入 Request，但前提是它被框架自动实例化（即走标准调度流程）。如果绕过调度直接 new，$this->request 就不会被赋值。
- 闭包路由中要访问 request，必须显式传参：
Route::get('test', function (Request $request) { ... });； - 自定义控制器类若继承
think\Controller，但没走 dispatch 流程（比如 CLI 调用），需手动绑定：$controller->assign('request', app('request'))； - 更稳妥的方式是任何时候都用
app('request')获取，而不是依赖$this->request—— 后者只是语法糖，且有上下文限制。
生命周期末尾还能操作 Request 吗？
不能。在 app_end 钩子或响应发送后（Response::send() 执行完），Request 对象虽未销毁，但其内部状态（如已读取的输入流、缓存的参数）可能已失效或被重置。尤其在 Swoole 长连接模式下，协程结束前 Request 可能已被回收。
- 日志记录、审计等逻辑务必放在
app_begin、action_begin或中间件中； -
app_end钩子适合做资源清理（如关闭临时文件句柄），不适合再读取请求参数； - 如果必须在响应后记录 URI，建议在
action_end阶段提前把$request->url()存到静态变量或上下文容器里。
最易被忽略的一点：Request 生命周期和 PHP-FPM 进程生命周期不完全对齐 —— 它是框架内管理的对象，受路由阶段严格约束，不是“只要脚本没 exit 就一直能用”的东西。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
