前言
今天线上有个需求就是需要通过渠道来区分下发的运营素材，然后就是需要在请求头中加一个channel字段。
经过
于是我在请求文件里，加了如下代码
headers.channel = 'xxxxx'
然后我加完之后，将项目部署到测试环境，没太在意，过一会发现，诶？测试环境的接口怎么都不行了，vconsole的network怎么显示status为0？怎么显示network error，测试环境估计崩了，过了一会，我又部署到别的环境也是这样，然后觉得不太对，肯定是代码的问题，就去百度了一下status 0的原因，结果如下
W3C规范定义了 返回0的原因
-
- 网络错误
-
- 被取消的请求
-
- 跨域CORS
公司的WiFi可以上网，排除1；
代码中也没有取消请求，排除2；
那就只可能是跨域请求的问题，于是我打开火狐浏览器抓请求接口（为什么用火狐，因为对于跨域原因导致的，该浏览器会有比较明确的提示）
这不妥妥的是因为channel导致的跨域吗？后端行不行阿？
于是我信誓旦旦的找到后端，甩了上面的截图，你们那接口是不是做了跨域限制啊？
然后后端大佬就说：“请求头怎么会叫channel？”
我脑子一转，仔细看了下，马上看接口文档，发现文档的demo，是塞在请求头的Device的字段里，而不是单独的在请求头里的，立马尴尬的跟后端说：“没仔细看”。
闹了个大乌龙，于是我立马改了部署到测试环境，假装没事人一样，发现正常了。
总结
如果遇到status0的情况，可以从上面的情况逐一分析；如果是请求头里的额外字段，需要问服务端是否支持，有没有设置Access-Control-Expose-Headers；在这里讲述一下这个请求头的意义
Access-Control-Allow-Headers
Access-Control-Allow-Headers头的作用是允许服务器指定哪些自定义请求头可以被浏览器访问。
通常情况下，浏览器只允许访问一些常见的请求头，如Content-Type和Authorization。但是，如果 Web 应用程序需要在请求头中使用自定义字段，则需要在服务器端配置Access-Control-Allow-Headers来允许浏览器访问它们。
例如，假设你正在开发一个 Web 应用程序，需要在请求头中包含一个名为“X-Custom-Header”的自定义头。如果服务器不允许访问该头，则浏览器将会拒绝该请求，因为它包含了未授权的请求头。为了允许浏览器访问该自定义头，服务器需要返回以下响应头信息:
Access-Control-Allow-Headers: X-Custom-Header
想了解CROS跨域的直接去看阮一峰大佬的文章，非常详细
