跨域问题技巧（最直白的跨域讲解）
跨域问题技巧（最直白的跨域讲解）同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。官方说明：我心中欢喜：哈哈，是时候展现真正的技术了！要弄清楚跨域，先看看为什么出现跨域问题。为了消除测试的疑惑，先给测试妹子说了说浏览器的同源策略。
作为一名敬业的搬砖者，励志扫荡一切bug，让测试没办法搞事情。
今天，测试妹子提了一个Bug，内容是这样的：
Nginx配置了2个设备IP，可访问接口时，只能展示其中一个设备的数据。
原来是跨域的问题哦，测试妹子问：什么是跨域？
我心中欢喜：哈哈，是时候展现真正的技术了！
要弄清楚跨域，先看看为什么出现跨域问题。
为了消除测试的疑惑，先给测试妹子说了说浏览器的同源策略。
官方说明：
同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。
这是一个用于隔离潜在恶意文件的重要安全机制。
怎么判断同源？如果两个页面协议、端口和IP（域名）都相同，则同源；否则就不同源。
举例，与http://test.com/test相比：
http://test.com/doc同源，协议和IP和端口（未指定默认80）相同。 ftp://test.com/test不同源，协议不同。 http://test.com：81/test不同源，端口不同。 http://test.test.com/test不同源，域名不同。
其中，IE浏览器例外。
如果是判断2个相互之间高度互信的域名，如公司域名，不遵守同源策略。
IE浏览器也未将端口号加入判断是否同源的条件中。
由此可见，IE浏览器兼容性真的差，就是有很特殊之处，让开发者很讨厌却没办法。
清楚了同源策略，那么就知道浏览器搞这个其实是为安全着想，那这个安全机制有什么用？
没有同源策略限制的后果据了解，浏览器是从接口请求和Dom查询这2个方面进行同源策略。
设想下，如果没有同源策略限制，当做出上述2个操作时，会有什么后果？
没有同源策略的接口请求
浏览器发送请求后，服务器接收请求后在响应头加入Set-cookie字段。
浏览器下次再发送请求时，自动附加cookie信息，服务器就能知道这个页面已经请求过了。
看看一个实际生活中的例子：
- 打开银行网站test.com进行转账等操作，甚至顺便浏览下基金的情况。
- 过程中，好基友发送了一个分享链接share.com，你打开了。
- 你浏览分享内容，因为没有同源限制，这个网站很可恶的向test.com发送请求。
- 进行了上面讲述的附加cookie过程，这样一番骚操作，分享链接网站登陆你的银行账号为所欲为……
这就是传说中CSRF攻击。
没有同源策略的Dom查询
再看看实际例子：
- 有天听说基金降的很凶，你很着急，赶紧登陆银行账号，查看到底亏了多少。
- 火急火燎的你没看清楚，平时登陆的网站是test.com，而今天访问的是tes.com，这个不可描述的网站可以做哪些操作呢？
- 因为没有同源策略限制，网站可以拿到test.com的Dom，获取银行账号和密码是分分钟的事。
由此可知，同源策略其实是浏览器的一种保护机制。
因为同源策略，出现了跨域问题。那么该如何解决呢？
下面祭出咱们的终端武器jsonp，全称json with padding，是为了解决跨域请求资源而产生的解决方案。
jsonp可以从基于script标签、jquery、iframe实现跨域，当然还有其他解决跨域问题。
具体怎么实现，测试妹子说：不想看具体的代码了，遂作罢遁走改Bug。
