TP6跨域请求被拦截主因是OPTIONS预检未响应、Access-Control-Allow-Origin与credentials冲突或中间件未生效；须通过$response对象动态设置头、前置注册中间件、精确匹配Origin白名单并确保Nginx不重复添加CORS头。
TP6 的跨域请求被拦截，90% 是因为 OPTIONS 预检没响应、Access-Control-Allow-Origin 和 credentials 冲突，或中间件根本没生效。
为什么全局中间件写了却没 CORS 头？
直接在中间件里写 header() 函数基本无效 —— TP6 使用 PSR-7 响应对象，手动调用会被后续流程覆盖。必须操作 $response 实例：
- 确保你在
return $next($request)之后拿到返回的$response，再调用$response->header() - 别在
$next($request)前设头，那会作用于请求对象而非响应 - 中间件注册位置错误：必须放在
app/middleware.php全局数组**首位**，否则可能被 session 或 auth 中间件拦截后绕过 - 若用了路由分组（如
Route::group('api', ...)），还要确认该分组显式挂载了 CORS 中间件，否则非 API 路由不走它
OPTIONS 预检失败：405 或静默卡住
浏览器对带 Authorization、Content-Type: application/json 或自定义头（如 X-Token）的请求，必先发 OPTIONS。TP6 不自动处理，必须手动拦截并返回 204：
- 开头加判断：
if ($request->isOptions()) { return response('', 204); } - 返回 204，不是 200；空响应体，不带 JSON 或 HTML
- 204 响应里必须含
Access-Control-Allow-Methods和Access-Control-Allow-Headers，且后者要精确覆盖前端实际发送的头（比如你前端发了X-Token，Allow-Headers就得包含它） - 别在同一个中间件里既返回 204 又继续执行
$next($request)—— 这会导致逻辑混乱甚至报错
带 Cookie 的请求始终失败？Origin 和 credentials 必须同时对齐
前端设了 credentials: 'include'，后端就绝不能用 Access-Control-Allow-Origin: *，否则浏览器直接拒绝，连控制台都不报错。
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
立即学习“PHP免费学习笔记（深入）”；
- 必须动态读取请求头：
$origin = $request->header('origin') - 白名单从配置读取（如
config('cors.allow_origins')），内容为完整协议+域名+端口（https://admin.example.com，不是admin.example.com） - 仅当
$origin在白名单内，才设置：$response->header('Access-Control-Allow-Origin', $origin)和$response->header('Access-Control-Allow-Credentials', 'true') - Nginx 或 Apache 层如果也加了 CORS 头，务必关掉，否则会出现重复头报错：
The 'Access-Control-Allow-Origin' header contains multiple values
路由级 allowCrossDomain() 为什么没反应？
这个方法只对显式声明的 HTTP 路由有效，且极易因链式调用遗漏或执行顺序错位而失效：
- 必须写成：
Route::post('api/login', 'LoginController@login')->allowCrossDomain(['https://admin.example.com'], true) - 不能写在闭包路由里漏括号，也不能拆成两行（
->allowCrossDomain(...)必须紧跟路由定义） - 它本质是给该路由绑定一个轻量中间件，**不覆盖全局中间件**；如果全局中间件已存在且顺序靠前，它的头可能被覆盖
- 开发时常用
*测试，但只要第二个参数为true（启用 credentials），*就立刻失效 —— 所以生产环境必须指定域名数组
真正容易被忽略的是：预检响应里的 Access-Control-Allow-Headers 必须和前端发的每一个自定义头完全一致，少一个字母都会导致预检失败；而这个头一旦设错，浏览器不会告诉你缺了哪个，只会静默终止请求。
