根据 https://www.rfc-editor.org/rfc/rfc9110.html#name-options 提到的关于 HTTP OPTIONS 请求的唯一响应是 200。但是，似乎存在以下情况：内容长度为 0，204 更合适。 HTTP OPTIONS 请求返回 204 是否合适？
RFC 2616 说：
200 回复应该...
...
如果不包含响应正文，则响应必须包含 字段值为“0”的内容长度字段。
这确实让人不清楚 200 是适用于整个段落还是仅适用于第一句话。如果你想安全起见，你应该让“必须”优先（而且这不会花费你太多）。
RFC 7231 废弃了 RFC 2616，将措辞更改为
服务器对 OPTIONS 生成成功响应应该...
...
如果响应中没有发送有效负载主体，服务器必须生成值为“0”的 Content-Length 字段。
这使得最后一句适用于一般意义上的 2xx 状态，并且必须优先。
因此，必须发送Content-Length。但是 Content-Length 不能与 204 一起发送：
RFC 2616 是这样说的：
请求中消息正文的存在是通过包含 Content-Length 或 Transfer-Encoding 标头字段来表示的...
... 所有 1xx（信息性）、204（无内容）和 304（未修改）响应不得包含消息正文。
RFC 7230 也澄清了这一点：
服务器不得在状态代码为 1xx（信息）或 204（无内容）的任何响应中发送 Content-Length 标头字段。
反正我是这么理解的。
是的，它可以返回 204。或 400。或 404。对于方法可以返回什么状态代码没有一般限制。
另请注意，是时候停止查看 RFC 2616 了。请参阅 https://httpwg.org/。
在现有语言中，解决RFC 7230 §3.3.2
Content-Length“服务器不得在状态代码为 1xx（信息）或 204（无内容）的任何响应中发送
Content-LengthOPTIONS“如果响应中不发送有效负载主体，服务器必须生成值为“0”的
Content-Length是禁止对
OPTIONSContent-That理想情况下，200 表示成功和响应详细信息，204 表示成功但没有任何响应。
例如 获取员工 e1 : 200 以及响应中的员工详细信息 获取员工 e2：204，但响应中没有员工详细信息