Swoole如何做跨域处理？跨域请求如何支持？

swoole处理跨域需在onrequest中设置cors响应头，关键在于正确处理options预检请求并返回access-control-allow-origin、methods、headers等头部信息，同时对实际请求添加相应头信息；生产环境应避免使用*通配符，推荐结合hyperf、easyswoole等支持中间件的框架实现更优雅的跨域解决方案，提升代码复用性与可维护性。

Swoole处理跨域，核心在于理解并正确设置HTTP响应头，尤其是针对浏览器发起的预检请求（OPTIONS方法）。这意味着你需要在Swoole的HTTP服务器回调中，根据请求的

Origin

Access-Control-Request-Method

Access-Control-Request-Headers

Access-Control-Allow-Origin

Access-Control-Allow-Methods

Access-Control-Allow-Headers

解决方案

在Swoole中实现跨域支持，主要是在

onRequest

首先，你需要捕获所有传入的HTTP请求。当请求方法是

OPTIONS

一个基本的实现思路是这样的：

use Swoole\Http\Server;
use Swoole\Http\Request;
use Swoole\Http\Response;

$http = new Server("0.0.0.0", 9501);

$http->on("start", function (Server $server) {
    echo "Swoole http server is started at http://127.0.0.1:9501\n";
});

$http->on("request", function (Request $request, Response $response) {
    // 设置通用的CORS响应头
    $response->header('Access-Control-Allow-Origin', $request->header['origin'] ?? '*'); // 允许所有来源，或指定来源
    $response->header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
    $response->header('Access-Control-Allow-Headers', 'Content-Type, Authorization, X-Requested-With');
    $response->header('Access-Control-Allow-Credentials', 'true'); // 如果需要支持Cookie等凭证

    // 处理预检请求 (OPTIONS)
    if ($request->getMethod() === 'OPTIONS') {
        $response->status(204); // 通常返回204 No Content
        $response->end();
        return;
    }

    // 实际业务逻辑处理
    if ($request->get['name'] ?? null) {
        $response->end("Hello, " . $request->get['name']);
    } else {
        $response->end("Hello, Swoole!");
    }
});

$http->start();

在这段代码里，

Access-Control-Allow-Origin

Origin

*

Access-Control-Allow-Methods

Access-Control-Allow-Headers

Access-Control-Allow-Credentials

为什么会出现跨域问题？它和Swoole有什么关系？

说起来，跨域问题本质上是浏览器的一种安全机制，叫做“同源策略”（Same-Origin Policy）。这玩意儿的目的很简单：防止恶意网站在用户不知情的情况下，通过JavaScript访问或操作其他网站的资源。比如，你登录了银行网站，一个钓鱼网站想通过JS去请求银行的API，同源策略就把它拦下来了。

同源的定义是协议、域名和端口都相同。只要有一个不一样，那就“跨”了。

Swoole作为底层网络通信框架，它本身并不知道什么叫“同源策略”，它只是一个高效的HTTP服务器。当浏览器向Swoole构建的后端服务发起一个跨域请求时，Swoole会正常接收并处理。但问题出在浏览器端：它在收到Swoole的响应后，会检查响应头中是否包含了CORS相关的许可信息。如果Swoole没有正确设置这些头，浏览器就会认为这个响应不符合同源策略，从而拒绝将响应内容暴露给前端JavaScript代码，即使数据已经成功从Swoole发回了。

所以，Swoole和跨域的关系在于：Swoole提供了构建HTTP服务的强大能力，但它不会自动帮你处理CORS。你需要手动在Swoole的HTTP响应中加入必要的CORS头部信息，来“告诉”浏览器：“嘿，这个资源是允许跨域访问的，放行吧！”这有点像你盖了座大楼（Swoole服务），但要让不同身份的人（不同域名）都能进来，你得在门口贴上明确的通行证（CORS头）。

What-the-Diff

检查请求差异，自动生成更改描述

下载

在Swoole中处理CORS预检请求（OPTIONS）有哪些关键点？

处理

OPTIONS

GET

POST

浏览器在发送一些“复杂”的HTTP请求之前，例如

POST

PUT

DELETE

OPTIONS

Swoole处理

OPTIONS

1. 识别请求方法： 你必须在

   onRequest

   回调中，第一时间判断当前请求的方法是不是

   OPTIONS

   。
2. 设置预检响应头： 对

   OPTIONS

   请求的响应，需要包含以下关键CORS头：

   • Access-Control-Allow-Origin

     : 告知浏览器允许哪些源访问。

   • Access-Control-Allow-Methods

     : 告知浏览器允许实际请求使用哪些HTTP方法。

   • Access-Control-Allow-Headers

     : 告知浏览器允许实际请求携带哪些自定义头。

   • Access-Control-Max-Age

     : 这个头非常重要，它指定了预检请求的响应可以被浏览器缓存多长时间（秒）。设置一个合理的值可以减少不必要的预检请求，提升性能。
3. 返回状态码： 通常，预检请求成功后，服务器会返回

   204 No Content

   或

   200 OK

   状态码，并且响应体是空的。
4. 立即结束响应： 最关键的一点是，在处理完

   OPTIONS

   请求并发送响应后，必须立即结束当前请求的处理流程。你不能让

   OPTIONS

   请求进入到你的业务逻辑层，因为它只是一个“问路”的请求，不是实际的数据请求。

如果Swoole没有正确响应

OPTIONS

除了手动设置HTTP头，Swoole生态中有没有更优雅的跨域解决方案？

当然有，手动在每个

onRequest

在Swoole生态中，更优雅的解决方案通常是结合中间件（Middleware）机制。虽然Swoole本身是一个底层框架，没有内置像Laravel或Express那样的中间件系统，但很多基于Swoole构建的高级框架或社区库都提供了这种能力。

• Swoole高级框架： 如果你使用的是像Hyperf、EasySwoole、Swoft这类基于Swoole构建的PHP框架，它们通常都会提供开箱即用的CORS中间件。你只需要在配置文件中简单开启或配置一下，框架就会自动帮你处理所有CORS相关的HTTP头和

  OPTIONS

  预检请求。这大大简化了开发工作，并且这些框架的中间件通常经过了良好的测试和优化。
• 自定义中间件层： 即使你没有使用这些大型框架，只是用原生Swoole，你也可以自己构建一个简单的中间件层。例如，你可以定义一个请求处理链，将CORS处理逻辑封装成一个独立的中间件。在每个请求到来时，先经过CORS中间件，它负责检查并设置CORS头，如果是

  OPTIONS

  请求就直接终止，否则就将请求传递给下一个业务逻辑中间件或控制器。

这种中间件模式的好处是：

1. 代码复用： CORS逻辑只写一次，所有请求都能享用。
2. 职责分离： 业务逻辑和CORS处理分离，代码更清晰。
3. 可维护性： 需要调整CORS策略时，只需要修改中间件即可。

在我看来，对于任何非简单的Swoole项目，引入一个合适的中间件层来处理CORS，几乎是必选项。它能让你的代码更健壮，也让开发者更专注于业务本身，而不是重复地处理这些HTTP协议细节。