这些年我们处理过的跨域
同源策略
在说跨域之前，我们需要先了解下 同源策略。它是一个规范（Netscape 1995年提出），并没有指定具体的使用范围和实现方式。
为了保证使用者信息的安全，防止恶意网站篡改用户数据，一些常见的Web技术都默认采用了同源策略（如Silverlight, Flash, XMLHttpRequest, Dom等）。
那如何判断同源呢？
- 相同的协议
- 相同的域名
- 相同的的端口号
我们用一个表格来展示同源的判断：
| URL1 | URL2 | 是否同源 | 分析 |
|---|---|---|---|
| http://www.a.com | https://www.a.com | 不同源 | 协议不一致 |
| http://www.a.com | http://www.b.com | 不同源 | 域名不一致 |
| http://www.a.com | http://www.a.com:8080 | 不同源 | 端口不一致 |
| http://www.a.com | http://test.a.com | 不同源 | 域名不一致 |
| http://www.a.com | http://www.a.com/test | 同源 | 判断同源和path无关 |
| http://www.a.com | http://www.a.com:80 | 同源 | 不带端口访问时，默认是80 |
如果不是同源会有哪些使用限制呢？
-
Cookie，WebStorage(LocalStorage, SessionStorage)，Cache(Application Cache, CacheStorage),Web DB(WebSql IndexDB)等都无法共享
-
无法彼此操作各自的DOM（Iframe）
-
无法发送Ajax请求
-
其他
注意：如果两个站点，具有相同的一级域名（如 www.a.com, test.a.com，一级域名都是a.com），那么可以通过各自设置document.domain='a.com' 来共享Cookie。
注意2：如果是iframe非同源，虽然不能操作dom，但是能操作location.href。
什么是跨域？
通过以上内容，我们了解到了什么是同源策略，以及怎么判断同源。那么与之相反，如果不满足同源，则就是跨域。
在浏览器上，如果访问跨域资源，将会有诸多限制（为了安全），参考上面的同源限制。
注意：跨域限制是浏览器的机制，如果直接在服务端请求，是不会触发跨域限制的。
那些我们遇到的跨域
1、图片跨域
对于图片来说，大部分场景是不需要处理跨域限制的，因为一般来说，图片没有跨域限制。
在也有例外，如果在 Canvas 中操作跨域的图片，那么就会触发跨域限制。解决办法是在返回图片的时候，添加 Access-Control-Allow-Origin: orign | '*' 来允许跨域。
2、Iframe跨域
这个也不太常见，如果网站本身和iframe嵌入的站点都是我们自己可以控制的，那么应直接使用 postMessage 来通信。如果浏览器较旧，不支持 postMessage ，可以考虑通过window.name来传递数据。
window.name 传递数据原理
首先在iframe访问跨域的站点，这个站点，将数据写入到window.name中。
然后主站点，修改iframe的location.href='about:blank' 或其他不跨域的站点。
最后通过window.name获取数据
这是因为同一个iframe的window.name是相互共享的。在现代浏览器中，该方式可能会失效，此时请使用 postMessage。
3、字体跨域
跨域使用字体文件，也会触发拦截。这个的解决办法和图片跨域一致，后端设置CORS头部即可。
4、Ajax跨域
这是我们经常会遇到的跨域问题，由于现在流行的开发模式，很多时候我们都需要处理这类型的跨域。
如何判断Ajax跨域
当我们在访问一个Ajax请求，控制台出现如下错误时，我们基本可以判断，是被跨域拦截了：
XMLHttpRequest cannot load xxxxx. No 'Access-Control-Allow-Origin' header is present on the requested resource.
很多时候，我们的API和Web并不在一个站点上（多个域名），而我们又必须要跨域访问。这个时候我们就需要想办法实现跨域资源访问。
以下，我们就来看看如何实现跨域资源访问：
CORS（跨域资源访问）- 标准做法，强烈推荐
开发模式的演进，导致我们很多的应用都是跨域访问。这个时候CORS规范也就应运而生了。使用它，我们可以直接对跨域资源进行访问，了解更多，请参考CORS详解。
该方式的核心是通过和后端API协商，看是否允许跨域访问。对于满足某些条件的请求，会先发送一个预请求。简单请求，也需要服务器允许跨域访问。
最关键的的几个响应头如下：
- Access-Control-Allow-Origin: origin | '*' 允许某个指定的域访问，*表示不限制域。
- Access-Control-Allow-Methods: 'GET,POST,PUT,DELETE' 允许哪些类型的请求
- Access-Control-Allow-Headers: 'x-token' 允许的自定义Header。
注意：该方式由服务端设置，前端无需设置，也无法设置。只要服务端处理好了，前端不需要做任何处理即可使用。
反向代理（将跨域代理为同域，绕过）
既然跨域有限制，那么我们可以考虑将跨域变成同域，这样不就没有限制了么？
以 Nginx 为例，我们只需要将特定路径的请求转发给真正的后端API即可：
server {
listen 8101;
root /dist;
index index.html;
location ~* \.(eot|ttf|woff|woff2)$ {
add_header x-server $server_addr;
add_header Access-Control-Allow-Origin '*';
}
location ^~ /api/v1 {
proxy_pass http://apis.xxx.com/api/v1;
}
}
注意：该方式需要在部署的时候做处理，前端需要修改请求api的地址为同域。
服务端转发（通过不跨域的请求跨域API，绕过）
该方式，通过请求不跨域的api，然后在api中再呼叫真实的跨域api，由于是服务端请求，所以也就避开了跨域问题。整体看来，这种方式有点多此一举，不过如果把这个转发由统一的程序进行处理，还是挺不错的。
注意：该方式在后端API中处理，前端需要修改请求api地址为同域。
JSONP（利用script无跨域限制，绕过）
该方式利用Script请求资源不会触发跨域限制这个特点来实现。JSON原理，请参考JSONP详解。
注意：该方式需要前后端搭配，后端需要支持JSONP请求，前端需要采用JSONP的方式去请求数据。
注意2：该方式由于实现原理限制，只能处理GET请求。
综上，遇到跨域请求，就先去找后端啊。前端真的独自搞不定啊。
总结
跨域是项目开发中，非常常见的问题。就算是前端开发，也一定要理解跨域，了解跨域的处理方案。以便于能够真正的处理好开发任务（或许，这样和后端交(Si)流(Bi)也更有底气）。
