一、为什么需要JS跨域
假设我们构建了一个网上商城www.xxx.com，出于对用户账号安全性的考虑，我们将用户登录统一到auth.xxx.com的子域下验证。当一个未登录用户浏览商品以后点击购买，为了提高网站的用户体验，我们想提供一个无刷新的登录入口。我们立刻想到使用AJAX实现无刷新的数据交互，可当我们实际使用AJAX向auth.xxx.com提交数据的时候，JS却出现错误提示，我们没有权限进行此操作，因为XMLHTTPRequest的实现要遵循浏览器的安全模型的同源策略规则，JS只能往自己的同源(同协议、同域名、同端口)发送XMLHTTPRequest请求，所以我们无法往子域发送AJAX请求。

解决此问题的通常做法是由auth.xxx.com提供接口，在www.xxx.com的域下做一个服务端代理。但随着业务的发展，我们又有a.xxx.com，b.xxx.com...等等都需要到auth.xxx.com做登录验证，那么我们需要在每一个子域下都有一个服务端的Proxy，值得庆幸的是这些子域都是我们自己的，对服务器上的程序有控制权，所以操作起来还是可行的。然而随着业务的继续发展，我们有越来越多的合作伙伴，现在我们要与他们实现部分数据的跨域互通，那么我们就需要和他们去约定一大堆的接口，然后自己逐一去实现Proxy，那么这种方式会带来很大的沟通和维护成本。有没有更好的方式呢？有！那就是客户端的JS跨域方案。

二、浏览器端的JS跨域方案
无论是子域还是非子域，JAVASCRIPT本身并没有官方的跨域实现，下面介绍的跨域方案都是开发者创造出来的巧妙的hack实现：
1、设置document.domain跨子域
2、使用iframe的hash
3、使用script标签
4、flash转发

上面各种方案的适用场景和开发成本也是不同的，你可以根据具体的情况来选择合适的跨域方案。

1、设置document.domain
如果仅仅是要跨子域，那么最简单的方式是设置document.domain，再配合隐藏的iframe，然后通过下面的方式来完成异步请求。
1.1 使用FORM提交
早期浏览器并不支持XMLHTTPRequest时，开发者就已经使用隐藏iframe和form的方式来做同源的异步数据提交，原理就是iframe间的相互通信。虽然我们现在是在子域间做异步数据提交，但通过设置domain我们已经获取了子域iframe之间的控制权(需要注意的是并没有直接使用XMLHTTPRequest往auth子域下的页面发送异步请求的权限)，那么下面要做的工作和以前没有区别，这里就大概描述一下，更具体的可以搜索下使用iframe做异步提交的资源。

我们在A页面(http://www.xxx.com/index.html)中以iframe形式插入一个auth子域下的B页面(http://auth.xxx.com/proxy.html)，并设置index.html和proxy.html页面的domain为xxx.com，这样index.html和proxy.html就有了互相访问的权限。

当用户在index.html输入登录信息提交时，我们可以获取到用户输入的用户名和密码，然后我们把此信息写入到proxy.html页面中。通常我们会在proxy页面中放置一个form，然后把需要提交的数据写入到此form中再提交此form，这样就完成了www到auth的数据提交。那我们怎么知道用户是否登录成功呢，我们需要一个反馈。proxy中的form对应的action页面接受到登录信息以后做验证，然后将反馈信息以JS脚本的形式输出，例如document.domain='xxx.com';top.showLogin({'code':'0','user':'yoyo'});，这样如果我们在index页面中定义了showLogin函数，那么用户登录以后就会自动调用，并且接收都到了auth的登录反馈。

1.2 使用XMLHTTPRequest提交

刚才我们是把数据通过proxy页面中的FORM提交出去的，实际上现在的主流浏览器都已经支持XMLHTTPRequest，我们完全可以控制proxy页面实例化一个XMLHTTPRequest对象，那么这个实例是在proxy的域下的，它是可以往auth.xxx.com提交AJAX请求的。这和我们页面本身发送AJAX请求所不同的仅仅在于操作的window对象不同，如果我们把这个差异封装起来，那使用者也是感受不到其中的差异的。

2、使用iframe的hash 同刚才的做法我们在A页面(http://www.xxx.com/index.html)中以iframe形式插入一个auth子域下的B页面(http://auth.xxx.com/proxy.html)，但这次我们不需要设置document.domain，受安全策略的限制A页面的JS无法获取到A页面中iframe的src属性，更没有办法访问页面B中的元素，但它可以设置iframe的src，假如A页面输入的用户名和密码同时以一定格式加入到了src对应的url中，例如：http://auth.xxx.com/proxy.html?user=yoyo&pwd=123456，B页面是可以在GET信息中获取此登录信息做验证的。这就完成了A到B的SET操作。那B登录验证以后怎么给A反馈呢？同理，我们可以在B页面以iframe形式引入一个www下的A_proxy页面(http://www.xxx.com/proxy.html)，那么它也可以通过设置iframe的src的方式实现B到A_proxy的SET操作，而A_proxy和A是一个域，他们之间就可以自由地完成通信了。

如果我们把参数以GET的形式设置到iframe的src中，会造成iframe频繁发送请求。为了避免这点，我们可以把参数以锚点的形式传入进入，同时在iframe里对锚点的改变做一个监听即可。那如何监听锚点的改变呢？
2.1：可以在iframe中使用setInterval频繁检查location.hash是否改变。如果你对你的代码效率有洁癖，那么你可以考虑使用下面的方法。
2.2：在设置iframe的src的同时，改变一下iframe的width属性，iframe内部使用onresize事件获知hash的改变。

此方法不局限于跨子域的需求，在FaceBook的APP平台中，第三方应用的iframe的高度自适应就是采用此方法实现的(实际上iframe高度自适应没有A到B的set需求，仅仅是B到A的set需求)。需要注意的是此方法的弊端在于做SET操作的时候受制于各个浏览器对url长度的限制，无法发送过多的数据。

3、使用script标签
当我们以script标签的src属性引入一个JS文件到页面中时，我们需要清楚下面两条规则：
3.1、文件下载完毕以后，其中的JS会自动运行。
3.2、无论src来源的域是什么，这段JS执行时信任的域都是此页面的域。

当用户登录的时候，A页面使用JS动态添加一个script节点到页面中，并且把用户名和密码设置到src属性中，例如：http://auth.xxx.com/login?user=yoyo&password=123456，那么完成了A到B的SET操作，当B做完验证以后，把结果以JS形式返回过来，例如：showLogin({'code':'0','user':'yoyo'})。根据规则一这个JS函数会自动执行，如果我们在页面A中定义了showLogin的函数，这就实现了B到A的回调反馈。

此方法的经典应用就是JSONP，它在此核心功能的基础上有定义了一些规则：例如返回值都是JSON格式，script标签的src中引入一个callback参数指定回调函数名。例如flickr的API，http://api.flickr.com/services/feeds/photos_public.gne?tags=cat&tagmode=any&format=json&jsoncallback=doSomething，返回的结果就是doSomething({JSON格式})，任何网站都可以通过JSONP调用此API来展示此照片列表。

在Jquery中也有getScript和getJSON的封装，它隐藏了script标签和回调函数的动态创建、垃圾回收、非跨域情况下的浏览器阻塞（具体细节的实现也是很有意思的，有空我会单独写一个分析），使用者只需要处理数据和回调函数即可。

此方法不局限于跨子域的需求，但由于它也是依赖设置script标签的src属性来做的set操作，所以它同样受制于各个浏览器对url长度的