CORS中间件未生效主因是注册顺序错误,须置于TrustProxies之后、其他中间件之前;同时需确保supports_credentials与allowed_origins不冲突,并正确处理预检请求。

为什么 cors 中间件没生效?检查中间件注册顺序
laravel 的 Cors 中间件必须放在 TrustProxies 之后、路由中间件之前,否则请求可能在到达 CORS 处理前就被拦截或修改。常见错误是把它加在全局中间件末尾,或漏掉 HandleCors::class 的显式注册。
正确做法是在 app/http/Kernel.php 的 $middleware 数组中确认位置:
protected $middleware = [ AppHttpMiddlewareTrustProxies::class, IlluminateHttpMiddlewareHandleCors::class, // ✅ 必须紧接在 TrustProxies 后 AppHttpMiddlewarePreventRequestsDuringMaintenance::class, // ... ];
- 如果只在某个路由组加
->middleware('cors'),要确保该中间件已定义在$routeMiddleware中(Laravel 9+ 默认已预置) - Laravel 8 及更早版本需手动安装
fruitcake/laravel-cors并发布配置,Laravel 9+ 内置HandleCors,无需额外包 - 使用
php artisan route:list检查目标路由是否实际绑定了cors中间件
config/cors.php 配置项怎么填才不被浏览器拒绝?
浏览器对 access-Control-Allow-Origin 值极其严格:不能同时设为 * 和启用凭据(withCredentials: true)。多数跨域失败源于这里配置矛盾。
典型安全配置(开发环境可放宽,生产务必收敛):
'allowed_origins' => ['https://your-frontend.com', 'http://localhost:3000'], 'allowed_methods' => ['*'], 'allowed_headers' => ['*'], 'exposed_headers' => [], 'max_age' => 0, 'supports_credentials' => true, // ⚠️ 开启时 allowed_origins 不能为 ['*']
-
supports_credentials设为true时,allowed_origins必须写具体域名,不能用通配符 -
allowed_headers若含自定义头(如X-Api-Key),必须显式列出,不能只靠*(部分浏览器不支持) -
exposed_headers是响应头白名单,前端 js 要读取的自定义响应头(如X-RateLimit-Remaining)必须在这里声明
POST/PUT 请求 405 或预检(OPTIONS)失败?检查路由定义和表单提交方式
浏览器对非简单请求(如带 json body、自定义 header、Content-Type: application/json)会先发 OPTIONS 预检。若后端没正确响应预检,后续请求直接被拦。
- Laravel 内置
HandleCors默认处理 OPTIONS 请求,但前提是路由存在且匹配——确保你的 API 路由支持OPTIONS方法,例如用Route::options()显式声明,或用Route::any()/Route::match(['get', 'post', 'options']) - 表单直接提交(
)不会触发预检,但 axios/Fetch 发送 JSON 会。检查前端是否误设了
Content-Type: application/json却没传 JSON 数据体 - csrf 保护与 CORS 冲突:API 路由应放在
api中间件组(默认禁用 CSRF),不要混用web中间件
chrome 控制台报 “No ‘Access-Control-Allow-Origin’ header” 但响应里有?缓存惹的祸
浏览器可能缓存了旧的 OPTIONS 响应(尤其是 max-age 设得大),导致新配置未生效。这不是代码问题,而是调试干扰。
- 强制刷新时勾选 “Disable cache”(DevTools → Network → 勾选)
- 临时把
max_age设为0,或改个配置值后清 Laravel 配置缓存:php artisan config:clear - 用
curl -I -X OPTIONS http://your-api.com/api/xxx直接看响应头,绕过浏览器缓存干扰 - 注意 nginx/apache 反向代理可能也缓存了 CORS 响应头,需检查服务器层配置
真正难调的往往不是中间件本身,而是浏览器预检逻辑、反向代理透传、以及前端是否真的按预期发出了带凭据或自定义头的请求——别急着改后端,先用 curl 或 postman 分离验证每一步。