通用的跨域处理方案
如果你是一枚前端工程师，我想应该或多或少对浏览器跨域请求有一些了解。
跨域的详细知识，就不再这篇文章里赘述了。
不太了解或者有兴趣了解一下的童鞋可以参考下 mdn 上的这篇文章：Cross-Origin Resource Sharing (CORS) - HTTP | MDN。
文章内容写的很详尽，相信你看完以后，一定会有种恍然大悟的感觉。
既然这篇文章，是想要记录下踩坑的历程，接下来肯定得详细记录下，坑出现在哪儿了。
一般情况下，出现需要跨域请求之时，对于要求不高的地方，直接改下 web 服务器的配置，允许所有的跨域请求即可，这也是最随意的做法。
简而言之，也就是直接朝响应头里添加 Access-Control-Allow-Origin: * 参数，代表能正常响应所有的跨域请求。
不过就像我前面所说的那样，之所以说随意，是因为，允许所有的跨域请求，是一种不太安全的行为，任何网站都可以随意的使用你提供的 web 服务。
甚至于，会让自己网站陷入跨域攻击的危险之中。
当然，如果你本身就想要提供公开的数据、业务接口，那么就可以直接采用上面那种简单粗暴的方式。
但是，如果不是出于上述目的的话，那么则不建议直接采用上面省事儿的方式。
一般我们可以采用增加白名单的方式，也就是只允许目标网站的请求，能够正常的响应：Access-Control-Allow-Origin: https://foo.example
复杂请求导致之前的跨域配置失效
而我们在实际应用的过程中，出于安全性考虑，一般都是由后端童鞋直接在 nginx 上统一进行跨域的配置，当然，肯定是采用第二种方式。
之前的项目采用这种配置方式，没有任何的问题。
但是最近做的一个项目，对于用户权限这一块，我们采用 token 的方式来处理，为了方便起见，直接将 Authorization 字段配置在请求头里了，方便对 api 请求进行权限控制。
但是在本地调试的时候，发现出现了跨域问题，接口死活调不通。
这个时候，可能有童鞋就要问了，现在不一般用 webpack 打包，在 webpack 的 devserver 里配置一下 proxy 模式不就行了。
起初碰到这个问题的时候，我也打算采用这个方式来解决，因为按照以往的经验来说，webpack devserver 相当于是起了一个 express 服务器，用它直接代理下我们的请求，就能避免前端跨域问题了。
但是不知道后端童鞋提供的 web 服务做了什么限制，走 express 代理的话，请求死活要过一分钟才会姗姗来迟的响应，与后端童鞋沟通过，无果，没找到解决方案，遂放弃了这种方式。
既然 express 代理的方式不可行，那就只能硬着头皮研究一下，为何明明配置了跨域，还是会提示跨域，死活调不通接口呢。
在找问题的过程中，我一度陷入了自我怀疑了。
为了确认不是前端代码层面的问题，确实是跨域导致的问题。我将项目打包以后朝服务器部署了一份，在非跨域的时候访问，果然一切正常，接口能正常请求到数据了。
这说明，确实是跨域引起的问题，正如 chrome 的 devtools 提示的那样。
这时候，我灵机一动，为啥我不换个浏览器试试呢？
于是我用 firefox 测试，尝试重新调用后台接口请求数据，才终于发现问题所在。
原来是因为预检请求（option）没有配置允许跨域，导致请求后台接口的时候一直失败，并且刚好还提示是跨域的问题。
为啥 chrome 的 devtools 没有清楚的显示出来，是因为预检请求导致跨域调用接口失败了呢？
带着这样的疑问，我 google 了一下，原来是因为从 Chrome 79 版本开始，preflight cors request 相关信息就被隐藏掉了，变成了隐藏功能，并且从 2020.01.06 开始，这个功能将被彻底隐藏掉，不再提供相关功能了。
详细情况，可以阅读下相关页面：OOR-CORS: Out of Renderer CORS
说实话，说这个消息令我震惊也不为过了。
因为以前我用 chrome 的时候，确实发现他支持显示 cors 相关的信息，后来我潜意识里一直就以为，这个功能一直是存在的。
我压根就不会想到，这个功能会在 chrome 里被砍掉。
可怕的是，用了这么久，我居然一直没有发现，居然存在这样的问题。
只能说以前之所以没发现问题，是因为恰好没碰到过这样的问题，在多种因素的作用下，导致最近这个问题才浮出水面，终于被我发现了。
我稍微回想了一下，之所以现在才意识到这个问题，有几个方面的原因：
- 有些情况下，直接配置了
Access-Control-Allow-Origin: *，导致根本不会遇到会有跨域的问题出现 - 有些情况下，都是简单请求，不会触发预检请求
- 有些情况下，即使出现需要预检请求，可能也针对所有的请求进行过配置，不像这位同事的做法，只是针对 get、post、put 等请求进行了跨域配置
所以我更加深刻的理解了，有时候，项目的代码能正常跑起来，确实是无数个巧合拼凑在一起的结果，要是没有深刻的理清各种技术的细枝末节，一旦出了点 bug，就会困扰很久，才能发现问题所在。
而且，这个问题，在越大、越复杂的项目中，更容易显现。
水落石出
闲话不多说，拉回到我们的正题。
既然我们现在已经发现问题所在了，聊聊解决方案吧。
如果你也用 nginx 的话，可以像这样配置一下，针对所有的预检请求，允许其跨域，并返回 204，就能解决 option 跨域的问题了。
当然如果你不想允许所有的域名都能跨域发送预检请求，并被服务器正常响应，把 * 改成允许的域名的列表就好了。
碰到了这个问题后，也让我开始思考之前大家一直讨论过的问题，chrome 开始垄断桌面端服务器的市场，让 google 都快成为 web 标准协议的制定者了，这其实并不是一种好现象。
屠龙勇士最终也终于变成了恶龙。
这个故事，应用在 chrome 和 ie 身上，同样适用。
所以为了反对垄断，我们更应该多支持下，用起来不是那么顺手的一些软件。
这放在任何领域都是适用的，有了竞争才有差异化，才会想着提升产品、提升服务，一家独大、垄断，无论是对于科技的进步还是普通用户的利益来说，都是有害的。