Octane下$request->query()仍可用，但需注意生命周期差异：$request对象每次请求新建故安全，而$_GET等超全局变量不重置易出错；应避免在构造函数、boot()等非请求上下文中缓存查询结果，且不可依赖$_GET获取URL参数。
Octane下$request->query()仍可用，但需注意生命周期差异
Octane 启动后会常驻内存，复用同一个 Laravel 应用实例处理多个请求。这意味着 $_GET、$_POST 等超全局变量**不会随每次请求重置**——但 Laravel 的 $request 对象是每次请求新建的，所以 $request->query()、$request->input() 依然安全可用。
真正容易出错的是：有人在中间件或服务容器中缓存了 $request->query->all() 结果，导致后续请求读到上一次的值。
- ✅ 正确做法：所有参数读取都在控制器方法或中间件
handle()内部调用$request->input('key')或$request->query('key') - ❌ 错误做法：在构造函数、
boot()方法或单例服务里提前保存$request->query->all() - ⚠️ 特别注意：
request()->query是静态代理，底层仍走当前请求上下文，但若在 Octane 的「预热阶段」（如octane:roadrunner启动时）调用，可能返回空或默认值
URL 参数解析依赖 Request 实例，不能依赖 $_GET
在 Octane 环境中，$_GET 可能被复用或未及时更新，尤其在 Swoole / RoadRunner 下，PHP 超全局变量行为不稳定。Laravel 的 Request 类内部通过 parse_str() + $request->server->get('QUERY_STRING') 重新解析，才是可靠来源。
- ✅ 始终用
$request->query('search')或$request->input('search')，二者在 GET 场景下等价 - ❌ 避免直接访问
$_GET['search']，即使它“看起来”能用，也存在偶发错乱风险 - ? 验证方式：在控制器里打印
var_dump($_GET, $request->query->all())，对比多次请求是否一致 —— Octane 下前者常滞后
路由参数与查询参数别混用，$request->route() 不含 query
很多人以为 request()->route()->parameter('id') 能拿到 URL 中的 ?id=123，其实不能。route()->parameter() 只解析路径段（如 /post/{id}），而 ?id=123 属于 query string，必须走 $request->query() 或 $request->input()。
- ✅
/user/123?tab=profile→request()->route()->parameter('id')得"123"，$request->query('tab')得"profile" - ❌
request()->route()->parameter('tab')返回null，因为tab不是路由定义中的占位符 - ? 小技巧：如果想统一处理，用
$request->input('tab', 'default')，它自动合并 query/post/json，且支持默认值
Octane 预热阶段 request() 返回空，别在 boot() 里读参数
Octane 启动时会执行一次「预热」（warmup），此时还没有真实 HTTP 请求，request() 或 app('request') 返回的是空实例或默认值。常见踩坑点是把参数读取逻辑写在服务提供者的 boot() 方法里。
- ✅ 参数读取只放在请求上下文中：控制器方法、中间件
handle()、闭包路由内 - ❌ 不要在
AppServiceProvider::boot()、config/app.php中调用request()->query() - ? 替代方案：需要动态配置？改用环境变量或配置缓存，而不是从 request 动态推导
