编写良好的HTTP服务器在获得CORS预检（OPTIONS）请求时应返回什么状态代码？
200，204还是其他什么？
如果允许原点（并且将设置相应的标题）或不允许（并且CORS标题不会被设置或与原点不匹配），状态代码是否应该不同？
它的要点是，只需使用200。
更一般地说：您应该发回与您发送回任何其他OPTIONS请求的CORS预检OPTIONS请求相同的状态代码。相关规范不要求或推荐任何其他内容。
至于相关规范：https://fetch.spec.whatwg.org/的Fetch规范是定义CORS协议要求的地方，它表示状态可以是200-299范围内的任意值。
这是来自CORS-preflight fetch algorithm，它有a step saying it can be any “ok status"：
如果请求和响应的CORS检查返回成功并且响应的状态为 一个ok status，运行这些子步骤：...
至于“正常状态”是什么，规范说明了这一点：
ok状态是
200到299范围内的任何状态。
除此之外，Fetch规范不建议200-299中的任何特定状态。
这里的另一个相关规范是HTTP 1.1规范，它有一个定义所有HTTP响应状态代码的语义的部分，在其中，a specific section that defines Successful 2xx代码。
在该部分内有a specific section for 200 OK，其中说：
The 200 (OK) status code indicates that the request has succeeded.
The payload sent in a 200 response depends on the request method.
For the methods defined by this specification, the intended meaning
of the payload can be summarized as:
…
OPTIONS a representation of the communications options;
因此，对CORS预检OPTIONS的响应只需要：
Access-Control-Allow-Methods和Access-Control-Allow-Headers响应头）这就是HTTP规范定义的200 OK，所以你可以在那里停下来。
但是，如果你通过the rest of the 2xx codes in that section阅读，你可以确认它们的语义没有一个对OPTIONS响应有意义 - 除了204 No Content。
现在，就204 No Content而言，将它用于OPTIONS响应并没有错 - 但据我所知，也没有任何意义。那是因为：
OPTIONS有效载荷没有用处OPTIONS（并且不会对任何有效载荷做任何事情）...所以据我所知，在204响应中使用特定的OPTIONS状态代码没有实际意义明确告诉客户没有有效负载。
但是，我可能错了，而且我缺少一些细微差别。但我不这么认为。
如果允许原点（并且将设置相应的标题）或不允许（并且CORS标题不会被设置或与原点不匹配），状态代码是否应该不同？
不，我认为不应该有所不同。我不知道除了你可以使用的200或204之外的标准定义代码 - 但无论如何，规范不要求它有任何不同，如果是，则不定义任何不同的用途。并考虑一下：由于这两种情况的状态代码有任何不同，现有客户代码会有什么不同？
如果这个问题的答案是“没什么”，据我所知，没有必要让它与众不同。
鉴于以上所有，底线是：只需发送200 OK进行CORS预检OPTIONS响应。发送除200 OK之外的任何代码都没有必要或没用。