跨域(CORS)预检请求中的路由匹配状态获取【协议兼容】-php教程-PHP中文网

跨域预检请求（options）不携带业务参数，服务端仅根据请求路径、origin、access-control-request-method和access-control-request-headers自主判断是否允许跨域，并返回符合cors规范的响应头。

跨域(cors)预检请求中的路由匹配状态获取【协议兼容】

跨域预检请求（OPTIONS）本身不携带业务参数，也不触发常规路由逻辑，它只关心“这个路径是否被允许以某种方式访问”。所以，路由匹配状态不是由前端传入的，而是由服务端根据当前请求路径和方法自主判断的。关键不在“获取”，而在“如何正确响应”。

预检请求的路由判断依据

浏览器发送预检时，会把实际请求的目标路径（如 /api/users）作为 OPTIONS 请求的 URL，同时带上两个关键头：

Origin：请求来源（如 https://admin.example.com）
Access-Control-Request-Method：后续将使用的 HTTP 方法（如 PUT）
Access-Control-Request-Headers：后续将携带的自定义头（如 Authorization, X-Trace-ID）

服务端不需要“解析路由参数”或“执行控制器逻辑”，只需检查：对这个路径 + 这个目标方法 + 这些头部，是否允许跨域？

不同框架中路由匹配状态的体现方式

所谓“匹配状态”，在实践中表现为服务端能否识别该路径并返回正确的 CORS 响应头。常见情况如下：

Skill Weave Chains — 技能链路由引擎

开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。

下载

Express/Koa 等中间件框架：需显式注册 router.options('/path') 或用通配中间件拦截所有 OPTIONS 请求；若未命中对应路由，会落入 404 处理流程，无法返回 CORS 头 → 预检失败
PHP（原生或轻量框架）：通常在入口文件开头统一判断 $_SERVER['REQUEST_METHOD'] === 'OPTIONS'，再根据 $_SERVER['REQUEST_URI'] 手动匹配路径前缀（如 strpos($_SERVER['REQUEST_URI'], '/api/') === 0）
ASP.NET Core：CORS 中间件默认不区分路径，但启用策略时可绑定到特定终结点（Endpoint Routing），此时路由匹配由 EndpointMatcher 完成，预检响应由 CORS 策略自动注入头，无需手动处理 OPTIONS

协议兼容的关键点：不要依赖“路由解析结果”

HTTP/1.1 和 HTTP/2 对 OPTIONS 请求的处理完全一致，差异只在传输层。真正影响兼容性的，是服务端是否遵循 CORS 规范返回标准响应头：

必须返回 204 No Content 或 200 OK（推荐 204）
必须设置 Access-Control-Allow-Origin（带凭证时不能为 *）
必须回传 Access-Control-Allow-Methods，且需包含预检中声明的 Access-Control-Request-Method
必须回传 Access-Control-Allow-Headers，覆盖 Access-Control-Request-Headers 中所有字段
避免在预检响应中写入 Content-Type 或响应体（除非用 200）

调试建议：用 curl 模拟真实预检行为

不要只看浏览器 Network 面板里的 OPTIONS 请求，它可能被 DevTools 自动省略部分头。用以下命令验证服务端是否真正支持：

curl -X OPTIONS \
  -H "Origin: https://example.com" \
  -H "Access-Control-Request-Method: PUT" \
  -H "Access-Control-Request-Headers: Authorization, X-User-ID" \
  -I https://your-api.com/api/profile

观察返回头是否完整、状态码是否为 204、Access-Control-Allow-Origin 是否匹配 Origin 值 —— 这才是协议层面真正的“路由匹配成功”信号。