浏览器发送options预检请求但后端未收到,主因是web服务器(如nginx)直接拦截返回405/501,或thinkphp未配置options路由及跨域中间件未提前终止请求并返回204响应。

为什么浏览器发了 OPTIONS 请求但后端没收到
ThinkPHP 默认不处理 OPTIONS 预检请求,除非你显式注册了对应路由或中间件拦截。它不是自动放行的——哪怕你写了跨域中间件,如果没覆盖 OPTIONS 方法,Nginx/Apache 也可能直接返回 405 或 501,根本到不了 PHP 层。
常见错误现象:Failed to load resource: the server responded with a status of 405 (Method Not Allowed),或者控制台只看到 OPTIONS 请求卡在 pending,没后续 POST/PUT。
- 确认 Web 服务器(如 Nginx)没有拦截
OPTIONS:检查是否配置了if ($request_method = 'OPTIONS') { ... }但没做add_header或return 204 - ThinkPHP 路由必须能匹配
OPTIONS方法:比如用Route::rule('api/:controller/:action', 'api/:controller/:action')->method('GET|POST|OPTIONS') - 跨域中间件必须在请求进入控制器前执行,且对
OPTIONS做短路响应(return $next($request)不能照常往下走)
如何让跨域中间件正确响应 OPTIONS 预检
关键不在“加 Header”,而在“提前终止请求流程”。预检请求不需要业务逻辑,中间件收到后应立即返回 204 或 200,并带上必要 CORS 头,不能继续调用 $next($request)。
典型错误写法:if ($request->isOptions()) { $response = response()->code(204); } 却忘了 return $response,结果仍走到控制器报错。
- 中间件中判断
$request->isOptions()后,必须return response()->code(204)->header(...) - 必需的响应头至少包括:
Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers、Access-Control-Allow-Credentials(如需 cookie) - 注意
Access-Control-Allow-Origin不能设为*同时又开启credentials,否则浏览器拒绝;此时得动态回传请求中的Origin值
if ($request->isOptions()) {
$origin = $request->header('origin', '');
$headers = [
'Access-Control-Allow-Origin' => $origin,
'Access-Control-Allow-Methods' => 'GET,POST,PUT,DELETE,OPTIONS',
'Access-Control-Allow-Headers' => 'Content-Type,Authorization,X-Requested-With',
'Access-Control-Allow-Credentials' => 'true',
'Access-Control-Max-Age' => '3600',
];
return response()->code(204)->header($headers);
}
为什么用了中间件还是跨域失败:Header 被覆盖或丢失
ThinkPHP 的响应对象是链式构建的,但中间件返回的 Response 如果没被最终响应器捕获,或被后续中间件/钩子重写,Header 就会丢。尤其在使用 think-swoole 或自定义 Response 扩展时更明显。
常见错误现象:抓包能看到 OPTIONS 返回了 204 和 CORS 头,但后续真实请求仍报跨域错误——说明浏览器没把预检结果缓存住,通常是因为 Access-Control-Max-Age 太小、Origin 不一致,或服务端响应头被覆盖。
- 检查是否在多个地方重复设置
Access-Control-Allow-Origin,比如 Nginx 已设,PHP 又设一次,可能触发冲突 -
Access-Control-Max-Age设太低(如 1)会导致频繁预检,增加失败概率;建议设为 3600 或更高 - 确保所有接口路径(含静态资源)都走同一套 CORS 策略,避免部分接口漏配中间件
- 如果用 Swoole,确认
Response实例未被复用,Header 不会被意外清空
兼容性与性能注意点:Swoole / FPM 下行为差异
FPM 模式下每次请求都是干净进程,Header 设置相对稳定;Swoole 是长连接常驻内存,Response 对象若被复用或缓存,可能导致 Header 累加或残留。
一个容易被忽略的坑:think-swoole 默认启用 enable_static_handler,静态资源(如 /static/js/app.js)可能绕过 PHP 中间件,导致这些路径无法响应 OPTIONS ——而前端恰好从该路径发起请求时就失败。
- Swoole 场景下,务必在
server.php或配置中关闭静态资源自动处理,改由 ThinkPHP 路由统一接管 - FPM 下注意
fastcgi_buffering on可能导致 Header 输出延迟,可临时关掉测试 - 预检请求本身无业务意义,别在里面查数据库或调远程服务,保持轻量,否则高并发时成瓶颈
OPTIONS 被 Web 服务器截胡、中间件忘了 return、或者 Access-Control-Allow-Origin 和 credentials 配对矛盾——这三处盯住,90% 的跨域预检问题就没了。php免费学习视频:立即使用
踏上前端学习之旅,开启通往精通之路!从前端基础到项目实战,循序渐进,一步一个脚印,迈向巅峰!











