我已经解决了这个问题。

if($_SERVER['REQUEST_METHOD'] == 'OPTIONS' && ENV == 'devel') {
    header('Access-Control-Allow-Origin: *');
    header('Access-Control-Allow-Headers: X-Requested-With');
    header("HTTP/1.1 200 OK");
    die();
}

这只是为了发展。这样我就可以等待9毫秒和500毫秒，而不是8秒和500毫秒。我可以这样做，因为生产JS应用程序将在同一台机器上生产，所以没有选项，但开发是我的本地。

OPTIONS请求是web浏览器的一个特性，所以要禁用它并不容易。但我找到了用代理转移的方法。如果服务端点还不能处理CORS/OPTIONS，可能还在开发中，或者配置错误，那么它就很有用。

步骤:

使用工具(nginx, YARP，…)为这些请求设置反向代理。 创建一个端点来处理OPTIONS请求。创建一个普通的空端点可能更容易，并确保它能很好地处理CORS。 为代理配置两组规则。一种是将所有OPTIONS请求路由到上面的虚拟端点。另一个是将所有其他请求路由到实际的问题端点。 更新网站以使用代理代替。

基本上这种方法是欺骗浏览器，选项请求工作。考虑到CORS并不是为了加强安全，而是为了放松同源政策，我希望这招能管用一段时间。：）

当您打开调试控制台并打开禁用缓存选项时，将始终发送预飞行请求(即在每个请求之前)。如果不禁用缓存，预运行请求将只发送一次(每个服务器)。

关于飞行前OPTIONS请求的实际需求，请参考以下答案:CORS -引入飞行前请求的动机是什么?

要禁用OPTIONS请求，ajax请求必须满足以下条件:

请求不设置自定义HTTP报头，如'application/xml'或'application/json'等 请求方法必须是GET、HEAD或POST中的一个。如果是POST，内容类型应该是application/x-www-form-urlencoded、multipart/form-data或text/plain

参考: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

你也可以使用API管理器(如开源的Gravitee.io)通过在preflight中操作头来防止前端应用程序和后端服务之间的CORS问题。

用于响应preflight请求的报头，以指示在发出实际请求时可以使用哪些HTTP报头:

内容类型 access-control-allow-header 授权 x-requested-with

并指定"allow-origin" = localhost:4200

在花了一整天半的时间试图解决类似的问题后，我发现这与IIS有关。

我的Web API项目是这样建立的:

// WebApiConfig.cs
public static void Register(HttpConfiguration config)
{
    var cors = new EnableCorsAttribute("*", "*", "*");
    config.EnableCors(cors);
    //...
}

我在网上没有CORS特定的配置选项。配置>系统。webServer节点，就像我在很多帖子中看到的那样

全局中没有特定于CORS的代码。Asax或在控制器中作为装饰器

问题在于应用程序池设置。

托管管道模式被设置为经典(更改为集成)，标识被设置为网络服务(更改为ApplicationPoolIdentity)

更改这些设置(并刷新应用程序池)为我解决了这个问题。