Laravel中间件需先在Kernel.php的$routeMiddleware中注册别名，再于路由中调用；构造函数不可注入Request，逻辑须在handle()中处理并必须return $next($request)。
中间件类怎么注册到 Laravel 路由里
中间件类写好了，但路由不生效？大概率是没在 app/Http/Kernel.php 里注册别名，或者注册后没在路由中引用。
- 全局中间件（如
VerifyCsrfToken）加到$middleware数组里，所有请求都会经过 - 分组中间件（如
auth、web）加到$middlewareGroups，再通过Route::middleware(['web'])或->middleware('auth')调用 - 自定义中间件必须先在
$routeMiddleware数组里配别名，比如'check.role' => \App\Http\Middleware\CheckRole::class，才能在路由里用->middleware('check.role') - 别名不能含点号以外的特殊字符，且不能和内置别名冲突（比如别起名叫
auth就会覆盖原生认证中间件）
Laravel 中间件构造函数里不能依赖注入 Request 或 Response
直接在中间件 __construct() 里写 public function __construct(Request $request) 会报错：Laravel 容器无法解析 Request 实例——因为中间件实例化发生在请求进入前，Request 尚未生成。
- 所有请求相关逻辑必须放在
handle()方法里，它接收$request和$next两个参数 - 如果需要提前校验某些配置或服务，可在
__construct()中注入非请求级依赖，比如ConfigRepository、Cache或自定义服务类 - 错误示例：
public function __construct(Request $request) { ... }→ 报Target [Illuminate\Http\Request] is not instantiable
中间件 handle() 里忘记调用 $next($request) 就会中断请求链
这是最隐蔽也最常踩的坑：中间件执行完逻辑后没放行，后续中间件和控制器完全不执行，浏览器卡住或返回空响应，日志里还找不到明显错误。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 必须显式返回
$next($request)，否则请求流就断了 - 如果是条件拦截（比如权限不足），应返回响应对象，例如
return response('Forbidden', 403)，而不是return或什么都不写 - 常见误写：
$next($request);（没 return）、return;、die('no');—— 这些都会让 Laravel 后续流程静默失败 - 建议养成习惯：handle 方法第一行写
return $next($request);，再在前面插入拦截逻辑
中间件顺序错了会导致 auth 或 session 失效
比如把自定义中间件放在 StartSession 前面，那你在中间件里读不到 $request->session()；放在 EncryptCookies 后面又可能解不开 session_id。
- 查看
app/Http/Kernel.php的$middleware数组顺序，越靠前越早执行 - 依赖 session 或 auth 的中间件，必须排在
StartSession和AuthenticateSession之后 - 涉及 cookie 加解密的，要确保在
EncryptCookies之后、AddQueuedCookiesToResponse之前 - 调试时可临时在中间件里
dd(get_class($this), $request->hasSession(), $request->session()->all() ?? 'no session');确认上下文是否就绪
中间件不是“写完就能用”的黑盒，它的生命周期紧耦合于 Laravel 的请求栈顺序和容器解析时机。哪怕只错一个位置、漏一个 return，整个请求就可能无声崩掉。
