本文介绍通过自定义中间件将一次请求中计算出的动态变量（如 $data1）注入到所有后续控制器请求中，实现安全、可维护的跨控制器数据共享。
在构建复杂的 Lara vel 应用时，我们常常会遇到一个典型场景：一个业务流程被拆分成多个步骤，比如一个多步表单。第一步，用户选择了预约的日期、时间和房间；第二步，需要基于第一步的查询结果（比如匹配到的所有用户ID），来提交消息内容。这时，如何把第一步控制器里计算出的动态数据，安全地传递给第二步的控制器，就成了一个必须解决的问题。
直接上全局变量？或者塞进 Session 里？甚至用静态属性？这些方法看似快捷，实则埋下了隐患。它们不仅违背了 Lara vel 请求生命周期的设计原则，更容易在并发访问时引发数据污染和状态不一致的“幽灵”问题。那么，有没有一种既优雅又安全的方法呢？答案是肯定的。核心思路就是利用 Lara vel 强大的中间件机制，在请求真正抵达控制器之前，就统一完成数据的注入和准备。
✅ 正确做法：创建可复用的中间件
首先，我们通过 Artisan 命令创建一个专属的中间件：
php artisan make:middleware CommonData
接下来，编辑 `app/Http/Middleware/CommonData.php` 文件。这里有三个关键点需要特别注意，它们直接决定了中间件的效率和安全性：
- ✅ 仅在需要时执行查询：切忌无条件执行耗时操作。务必通过判断请求中是否存在必要的参数，来决定是否加载 `$data1`。
- ✅ 使用 request() 辅助函数需谨慎：在中间件内部，更推荐使用注入的 `$request` 对象的 `input()` 方法，而非全局的 `request()` 辅助函数，这能确保代码上下文清晰，避免意外。
- ✅ 合理命名与作用域：这个中间件应该只应用于特定的、有关联的路由组（例如 `/message/store`），而不是全局注册，以免造成不必要的性能开销。
filled(['date', 'time', 'room_id'])) {
$data1 = Reservation::select('user_id')
->where('date', $request->input('date'))
->where('time', $request->input('time'))
->where('room_id', $request->input('room_id'))
->pluck('user_id') // 返回集合（如 [1, 5, 8]），更符合后续赋值逻辑
->toArray();
// 注入请求实例，供控制器安全访问
$request->merge(['shared_reservation_user_ids' => $data1]);
}
return $next($request);
}
}
? 在控制器中使用共享数据
现在，到了第二步的控制器（例如 `SecondController@store`）中，事情就变得非常简单了。我们完全不需要重复之前的查询逻辑，直接从当前请求中获取已注入的数据即可：
use Illuminate\Http\Request;
public function store(Request $request)
{
$msg = new \App\Models\Message(); // 显式使用完整命名空间
$msg->date = now(); // Carbon::now() 的简洁写法
$msg->content = $request->input('content');
$msg->user_id = auth()->id();
// ✅ 安全获取共享数据（返回数组，适配多用户场景）
$receiverIds = $request->input('shared_reservation_user_ids', []);
// 若需存入数据库（假设 reciver 是 JSON 字段或关联关系）
$msg->reciver = json_encode($receiverIds); // 示例：存为 JSON 字符串
// 或批量创建关联记录（更规范的做法）
$msg->sa ve();
return redirect()->back()->with('success', '消息已发送');
}
⚠️ 重要注意事项
- 不要全局注册此中间件：最佳实践是仅在 `routes/web.php` 中，对特定的目标路由分组进行应用：
Route::middleware(['common.data'])->group(function () { Route::post('/messages', [SecondController::class, 'store']); }); - 避免 Session 误用：虽然 Session 可以临时存储数据，但这里的 `$data1` 完全来源于当前请求的参数，其语义严格属于“本次请求的上下文”。将其持久化到 Session 中，极有可能导致不同用户或不同请求间的数据污染，这是必须警惕的。
- 类型安全提醒：`$request->input('shared_reservation_user_ids')` 可能返回 `null` 或数组，因此务必做好空值检查。如果业务上要求这些数据必须存在，更稳妥的做法是在表单请求验证层（Form Request）中，提前对 `date`、`time`、`room_id` 等参数进行校验。
- 性能优化建议：如果中间件内的查询非常频繁且结果相对稳定，可以考虑结合缓存机制（例如 `Cache::remember()`），根据查询参数生成一个哈希键来缓存结果，从而有效减轻数据库的压力。
通过这套方案，你不仅完美遵循了 Lara vel 请求驱动的架构哲学，更实现了一套清晰、可控且易于测试的跨控制器数据共享逻辑。这，才是符合 Lara vel 风格的最佳实践。
