thinkphp 6 默认不处理 options 请求，需手动注册路由或在 web 服务器层拦截；推荐在 route/app.php 中前置定义通配 options 路由并返回 204 响应及 cors 头。
ThinkPHP 6 的 OPTIONS 请求为什么没响应？
默认情况下，ThinkPHP 6 不会自动处理 OPTIONS 请求——它既不进路由，也不走中间件（除非显式配置），更不会触发控制器方法。如果你在调试跨域时看到浏览器预检请求（OPTIONS）返回 404 或空响应，大概率是因为框架根本没接管这个请求。
手动注册 OPTIONS 路由最稳妥
别依赖“自动响应”或“中间件拦截所有方法”，直接在 route/app.php 里明确定义：
// route/app.php
use think\facade\Route;
Route::options('*', function () {
return response()->code(204)
->header([
'Access-Control-Allow-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',
]);
});
注意几点：
-
*路由必须放在所有其他路由之前，否则会被更具体的路由拦截并报错 - 返回
204 No Content是标准做法，避免响应体引发二次解析问题 - 如果项目启用了
Access-Control-Allow-Credentials: true，则Access-Control-Allow-Origin不能为*，需动态匹配请求头中的Origin
用中间件统一处理 OPTIONS 的风险点
有人试图在中间件里判断 $request->method() === 'OPTIONS' 并提前返回，但要注意：
- 中间件执行时机晚于路由匹配，若路由未定义
OPTIONS，请求根本到不了中间件 - 全局中间件对所有请求生效，可能干扰正常业务逻辑（比如误吞掉某个接口的
OPTIONS子路径） - 若使用了多应用模式（
app/multi），中间件需注册到对应应用的middleware.php，而非全局
真要用中间件，建议只在 CORS 相关中间件中加一层保护：
<pre class="brush:php;toolbar:false;">if ($request->isOptions()) {
return response()->code(204)->header($corsHeaders);
}
Apache/Nginx 层提前响应 OPTIONS
更高效
如果只是解决跨域预检，Web 服务器层拦截比 PHP 层更快、更轻量。Nginx 示例：
location / {
if ($request_method = 'OPTIONS') {
add_header Access-Control-Allow-Origin "*";
add_header Access-Control-Allow-Methods "GET,POST,PUT,DELETE,OPTIONS";
add_header Access-Control-Allow-Headers "Content-Type,Authorization,X-Requested-With";
add_header Access-Control-Allow-Credentials "true";
add_header Access-Control-Max-Age "86400";
return 204;
}
}
这能完全绕过 PHP 解析，但前提是你的部署环境允许修改服务器配置；本地开发用内置 Server（php think run）时这条路行不通。
实际项目里，OPTIONS 响应容易被当成“配个 header 就完事”的小问题，但一旦涉及凭证、自定义 Header、多级代理或 CDN 缓存，行为就会变得微妙——务必在真实浏览器环境下用 Network 面板看预检请求的完整响应头，而不是只信 curl 或 Postman 的模拟结果。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
