api 中间件组不校验登录，因其仅含限流、模型绑定等基础能力，不含认证逻辑；auth:api 是独立注册的认证中间件，需显式组合使用。
中间件组不是“自动带认证”的别名，api 组默认不含 auth:api，混用会导致未登录请求静默通过。
为什么 Route::middleware(['api']) 不校验登录？
因为 api 是中间件组（定义在 $middlewareGroups），只包含限流、模型绑定等基础能力，不包含任何认证逻辑。它和 auth:api 完全无关——后者是单独注册在 $routeMiddleware 里的认证中间件。
-
api组内容示例（app/Http/Kernel.php）：throttle:240,1、bindings，没有auth:api - 若你期望 API 路由必须登录，得显式加：
->middleware(['api', 'auth:api'])或->middleware('api')->middleware('auth:api') - 直接写
->middleware('auth:api')也不行——它不自动继承api组的限流等能力，得手动补全
web 和 api 组的关键差异在哪？
两组底层行为完全不同，选错会引发 session 启动失败、CSRF 报错或 token 解析异常。
-
web组默认启用StartSession、VerifyCsrfToken，依赖 PHP session 文件或 Redis 存储；API 请求通常无 cookie，强行套用会抛Session store not set on request -
api组跳过 session 和 CSRF，改用 token（如 Sanctum/Breeze 的X-Sanctum-Token或 Bearer header）做认证 - 路由文件加载时机也不同：
routes/web.php自动包裹web组；routes/api.php自动包裹api组，但仅限该文件内定义的路由
自定义中间件组怎么安全注册？
往 $middlewareGroups 里追加新组时，顺序和成员选择直接影响执行链是否断裂。
- 别把
TrustProxies放在StartSession后面——代理头（如X-Forwarded-For）读不到，session ID 就会错乱 - 含 DB 查询的中间件（如租户识别）别塞进
api组高频路由里，先加缓存或判断$request->is('health*')排除健康检查 - 组内中间件顺序即执行顺序：前置逻辑（如日志开始时间）放前，后置逻辑（如响应耗时统计）放后，靠
$next($request)分隔
中间件组里的 $next($request) 被跳过会怎样？
不是报错，而是整个请求生命周期卡死：控制器不执行、视图不渲染、响应不返回，Nginx/Apache 最终触发超时，日志里只留一条空请求记录。
- 常见诱因：
if分支里写了return response(...)却漏了else分支的return $next($request) - 调试技巧：在
handle开头加Log::debug('in middleware X')，末尾加Log::debug('out middleware X')，看哪一层没打出 “out” - 别在中间件里调
exit或die——Laravel 的终止器（terminable middleware）、事件、日志 flush 全部失效
最易被忽略的是中间件组与单体中间件的职责边界：api 组管“通道能力”，auth:api 管“身份凭证”，两者必须显式组合，不能假设它们天然耦合。
