前端容易理解错的跨域原理（前端跨域产生的原因和解决方法）

关于跨域这件事，自从我遇到后，了解一下，这事就过去了。我也一直认为这是个小问题，大家应该都懂。直到我要教妹妹前端时遇上这个问题才发现，这个问题得整个逻辑讲出来其实还挺绕的。知道问题怎么解决很简单，但是要讲清楚问题为什么出现就十分复杂了。那么我突然就好奇了，大家是都懂这个逻辑了嘛。所以我在几个交流群里问了一个问题

为什么很多人都出现本地环境会跨域而线上环境不跨域得情况

得到的答案都不太正确，唯独一个前后端都做得同学答的很准确。这时候我大概明白了，其实是我的后端经历帮助我很好地理解了跨域，所以我才没有特别的感觉。那么我就从这个问题出发，聊聊跨域。

前端代码如何运行

先问大家两个看起来不太相关的问题。

我们前端得代码运行在哪？(非ssr)

服务器还是哪里，直接运行在系统上嘛。答案是运行在用户电脑得浏览器里。后端看到这个问题可能就想嘲讽了，你别说，我也去群里问了，还真有不少前端认为代码运行在服务器里。接着第二个问题。

用户的浏览器是怎么获取到我们的代码的？

从我们的服务器上拿？怎么拿？大概路径是这样的，通过域名请求访问到服务器，服务器的nginx软件(nginx为例，其他也可)回应请求，返回相应的前端代码文件。

什么是跨域

好，进入正题，首先甩出跨域定义什么是跨域

太多的概念我这里就不重复赘述了，我说一下我的理解：

上面已经提到我们的代码运行在浏览器内，所以浏览器对于不同源的限制其实是对我们代码的限制。限制的标准就是请求的地址端口和当前页面的地址端口是否一致。

那这个当前页面的地址端口是什么？看我们前面的第二个问题。所以其实是浏览器获取代码的地址和代码运行时请求的地址不一致导致的跨域。逻辑有没有清晰了一点？让我们回到前言的问题吧。

线上环境

线上环境一般是什么情况？可能大部分前端都不需要去管线上的配置，但是了解一下总归是好的。线上一般是服务器跑着一个nginx软件，由nginx来处理请求，如果是获取前端代码，就直接返回代码文件，如果是请求后端服务，就转发到后端的程序上，等待程序处理结果返回，然后nginx再把结果返回给用户。

那么问题来了，怎么分辨获取前端代码请求和后端服务请求呢？按域名分？api.xxx.com|admin.xxx.com? 这不好，这跨域了。一般情况都是同一个域名，按路径前缀区分，xxx.com/api/xxx|xxx.com/admin/xxx。 其实这里前端路径和后端服务路径是会出现冲突的，不过大家开发一般都不用api作为前缀所以很少有人遇到这种问题。

按路径前缀区分，那就不存在跨域问题了。

本地环境

本地大家基本上都是用cli，运行项目用命令，run、start什么的。我们看vue-cli的描述

vue-cli-service serve 命令会启动一个开发服务器 (基于 webpack-dev-server) 并附带开箱即用的模块热重载 (Hot-Module-Replacement)。

开发服务器是什么？一个虚拟机嘛？不是的，这里说的服务器实际上说的是服务器软件，也就是web服务软件，是跟nginx类似的软件，这里为了不容易混乱，我用nginx指代服务器软件，服务器还是指服务器机器。

这个本地运行的nginx(开发服务器)的作用就是监听localhost:8080这个地址的请求，并返回你写的代码。这里还提到附带了模块热重载，因为我们写的vue代码其实浏览器是识别不了的，不能直接返回，上线正式时要打包其实就是转化成原生的js代码，那热重载其实也是一个类似的步骤，但是它可以快速局部打包，方便你刚修改代码就能在浏览器看到效果。

后端服务的话一般要么是跑在同事的机器上，要么是自己电脑也运行着后端项目。拿后者来说，后端跑个nodejs项目的话，也是用cli跑个命令，同样也是启动了一个nginx，监听localhost:3000这个地址的请求。要注意咯，后端启动的nginx和前端启动的nginx并不是同一个，是各自运行的。

回归问题

前面我们说了线上环境一般都没有跨域，那我们想想，能不能让本地环境模拟线上的做法来解决跨域问题？

• 首先要用同一个域名和端口，像上面提到的本地环境那样，我们都监听localhost:8080怎么样？让两个nginx都监听同一个地址端口可以嘛？不行，端口会冲突的。
• 那可以把两个nginx合二为一嘛？也不行，因为cli的代码不好改，能改cli代码的人估计也不需要问跨域问题了。
• 那我可以直接在本地跑个真正得nginx，不要cli运行的nginx呢？也不行，因为cli运行得nginx还附带热重载功能而且很有必要，不然每次改代码都需要打包才能在浏览器看见效果，谁都接受不了吧。
• 那我可以直接在本地跑个真正得nginx，同时也要cli运行的nginx呢？这个方法确实可以，但是这跟线上的情况就不一样了，这个就是代理的逻辑了。具体就是运行一个真正的nginx，配置出另一个公共域名地址，比如localhost:8888，吧/api的请求转发到localhost:3000，把/admin的请求转发到localhost:8080，3个nginx同时运行。这个方法主要就是麻烦，代理可以看下面的方法。

同理，如果是后端服务跑在同事的机器上那就更加做不到了，因为连域名都不能一样。

到这里我想大家应该能理解到这个问题出现的原因了。

代理

我们常见的代理是怎么解决这个问题的？通常是在vue的配置文件里配置

devServer: {
    proxy: {
      '/api': {
        target: 'localhost:3000/',
        changeOrigin: true
      }
    }
},

这个配置的意思是告诉前端项目的nginx，对api前缀路径的请求，都转发到localhost:3000去。也就是把请求后端的地址改成localhost:8080，然后由前端nginx接管所有请求，类似线上nginx那样，用路径前缀区分请求，然后分别处理。虽然和线上稍有不同，不过这原理上基本是一样了，真是完美的解决方案。

其他方案

最典型的应该是CORS方案了。

总的来说解决跨域问题有两个方向，一种是绕开跨域限制，一种是解除跨域限制。代理属于前者，cors属于后者。nginx转发是相当于用类似postman的原理请求，是不受跨域限制的，因为跨域是浏览器的限制。所以由nginx转发就相当于绕开了限制。而cors是通过一定的配置令浏览器解除限制，需要后端配合。

如果线上环境不需要跨域，不建议大家采用解除限制的方案(CORS),因为Chrome在19年新增了跨域的限制，解除限制变得越来越麻烦

总结

总结一下，线上环境不跨域是因为同一个nginx处理同一个请求地址，而本地环境无法做到的原因是cli无法更改，只能通过配置代理达到类似的效果。

本文仅针对常见得前后端分离项目，ssr不在讨论范围。另外，补充一下，前面是为了简单说明所以直接用【获取前端代码】来表达，其实严谨点是获取html页面，也就是【浏览器限制当前地址html页面内运行的js代码访问其他域名】因为获取js代码其实是可以不同地方获取的，远古时代的jq很多人就是通过cdn地址(加速服务器)来拿的。这算不算跨域呢？不算，仔细看看同源策略。