「我认为这是现在的前端脚手架提供的一个极其糟糕的功能」 你这个观点不对。 本地开发服务器会提供接口代理，它的一个重要的背景是： 世界上绝大多数网页服务，网页域名跟接口域名是一样的，也就是线上一般不会存在跨域问题。 开发工具做这个代理逻辑，仅仅是为了跟线上保持一致而已。 确实存在接口域名跟网页域名不一样的时候，但是这不应该是常态。因为即使处理了跨域的问题，还有三方 cookie 的问题等着你。
@shadowyue 跨域请求，后端是有日志的。 而且如果是 GET 请求，在后端看来，甚至是一次成功的请求，它感知不到自己返回的结果被浏览器拦截了。 我们看到的“Access to fetch at 'xxxx' from origin 'xxxx' has been blocked by CORS policy”异常，是发生在接受返回值的阶段，而不是发请求的阶段： JS——>浏览器——>服务器——>浏览器— ⛔—>JS
@yuezhiyuan #49 浏览器是能接受任何响应头的。只是限制了 js 能读取哪些头。 想让 js 访问其它的响应头，需要用 Access-Control-Allow-Headers 来加白名单。
我觉得核心逻辑是清楚地，但是实际业务会因为一些框架或者代理之类的导致其他的异常的边界情况。并不能说这个问题就是这样。 我遇到过的边界情况包括但是不限于，运维同学 nginx 配置和研发同学代码框架冲突导致 header 被重复添加，旧的浏览器个别版本不支持 wildcard 等等等等。 这东西说难不难，但是实际业务中还是要跟着 response 去跟逻辑去处理或者规范框架配置。
