Origin标头的定义为：
origin-or-null = origin / %s"null" ; case-sensitive
"null"是否可以像域名一样管理？换句话说，当使用"null"时(至少在某些情况下)，服务器是否可以接受请求，或者它是否一直被视为故障？
我在Fetch文档中寻找了解释，但到目前为止，我还没有找到这个特定问题的答案。
通过发送Origin: null标头，浏览器指示请求来自不透明来源。也就是说，浏览器向作为服务器维护者的您发出信号，表明请求不是以典型的方式从实际运行在网络上的应用程序发起的，并使用Ajax方法或Fetch或XHR来调用您的服务器——因此，这可能不是您实际打算让服务支持的用例。
因此，在响应Origin: null请求时，您通常不希望发送Access-Control-Allow-Origin响应标头。换句话说，您希望浏览器阻止任何前端JavaScript代码访问您为此类请求发回的响应。
虽然浏览器将Origin标头设置为null时最常见的情况可能是从某人的本地文件系统(从file://URL而不是从Web服务器)运行前端代码时，但还有许多其他情况下浏览器也将Origin标头设置为null。有关详细列表，请参阅https://stackoverflow.com/a/42242802/441757.
https://w3c.github.io/webappsec-cors-for-developers/#avoid-返回access control allow origin null解释了您应该如何看待这种情况：
返回
Access-Control-Allow-Origin: "null"似乎是安全的，但任何使用非分层方案(如data:或file:)和沙盒文档的资源的Origin的序列化都被定义为"null"。许多用户代理会授予此类文档访问具有Access-Control-Allow-Origin: "null"标头的响应的权限，并且任何来源都可以创建具有"null"来源的恶意文档。因此，应避免ACAO标头的"null"值。
换句话说，如果您有意允许服务器的响应在某人的本地文件系统上运行的前端JavaScript代码中使用(例如，对于进行本地测试的某人)，那么您可能认为为Origin: null请求发回Access-Control-Allow-Origin会很有用。但是，这样做不仅允许本地文件系统的情况，还允许中描述的所有其他情况https://stackoverflow.com/a/42242802/441757.要么全有要么全无。