Webman需手动配置CORS响应头，推荐在中间件中处理：对OPTIONS请求返回204响应，并设置Access-Control-Allow-Origin等头字段；禁用通配符*配合credentials，确保预检通过且安全。
Webman 默认不自动处理跨域，必须手动配置 CORS 响应头，否则前端发请求会卡在预检（OPTIONS）阶段或报 No 'Access-Control-Allow-Origin' header is present 错误。
Webman 中间件里怎么写 CORS 头
Webman 的中间件是唯一推荐的、可复用且可控的方式。不能只靠 header() 函数，因为 Webman 使用响应对象链式构建，直接调用 PHP 原生 header() 可能被后续逻辑覆盖或失效。
- 创建中间件：运行
php webman make:middleware CorsMiddleware - 编辑
app/middleware/CorsMiddleware.php，在handle()方法中操作$response对象： - 先判断是否为 OPTIONS 请求：
if ($request->method() === 'OPTIONS') { return response('', 204); } - 再设置响应头：
$response->withHeader('Access-Control-Allow-Origin', 'https://your-frontend.com') - 若需支持凭证（如 Cookie、Authorization），必须指定具体域名，禁用
*，并加：$response->withHeader('Access-Control-Allow-Credentials', 'true') - 补全必要头：
Access-Control-Allow-Methods、Access-Control-Allow-Headers、Vary: Origin
为什么 Webman 不能像 ThinkPHP 那样用 ->allowCrossDomain()
Webman 是基于 Workerman 的轻量级框架，本身没有路由级 CORS 封装方法。ThinkPHP 的 ->allowCrossDomain() 是其路由 DSL 的语法糖，底层仍是中间件注入；Webman 路由定义不提供这类链式调用，所有响应控制必须落在中间件或控制器响应构造环节。
- Webman 的路由回调返回的是
Response实例，不是Route对象，无法链式扩展 - 试图在路由闭包里写
header()会触发headers already sent，因 Webman 已提前启动输出缓冲 - 想“偷懒”只在某个接口加头？只能在对应控制器方法里 return 新的
response()->withHeader(...)，但重复代码多，不推荐
OPTIONS 预检失败的典型表现和修复点
浏览器发了 OPTIONS 请求但没收到 200/204 响应，就会静默终止后续请求——你根本看不到实际接口的错误，只看到网络面板里 OPTIONS 显示 pending 或 405。
立即学习“PHP免费学习笔记（深入）”；
- 检查中间件是否真的生效：确认
app/middleware.php中已将CorsMiddleware::class加入全局中间件数组，且位置靠前（优先于鉴权、日志等） - 确认
$request->method()判断准确：Webman 用的是$request->method()，不是$request->isOptions()（后者不存在） - 不要漏掉
return response('', 204)：必须显式返回，不能只设 header 后return $next($request) - 如果用了 JWT 或 Session 鉴权中间件，确保它不会在 OPTIONS 阶段抛异常或重定向——预检请求不该触发业务逻辑
最易被忽略的是：生产环境必须把 Access-Control-Allow-Origin 从 * 换成明确域名，且一旦启用 credentials，这个值就绝不能是通配符——这点 Webman 不校验，但浏览器会直接拒绝响应。
