跨域来源于JavaScript的"同源策略"，即只有 协议+主机名+端口号 (如存在)相同，则允许相互访问。也就是说JavaScript只能访问和操作自己域下的资源，不能访问和操作其他域下的资源。跨域问题是 针对JS和ajax的，html本身没有跨域问题。
查看浏览器开发者工具Console报错：
Failed to load http://a.a.com:8080/A/FromServlet?userName=123: No ‘Access-Control-Allow-Origin‘ header is present on the requested resource. Origin ‘http://b.b.com:8080‘ is therefore not allowed access.
http://www.abc.com/a/b 调用 http://www.abc.com/d/c（非跨域）
http://www.abc.com/a/b 调用 http://www.def.com/a/b （跨域：域名不一致）
http://www.abc.com:8080/a/b 调用 http://www.abc.com:8081/d/c （跨域：端口不一致）
http://www.abc.com/a/b 调用 https://www.abc.com/d/c （跨域：协议不同）
请注意：localhost和127.0.0.1虽然都指向本机，但也属于跨域。
2.如何解决跨域？
(1).响应头添加Header允许访问
(2).jsonp 只支持get请求不支持post请求
(3).httpClient内部转发
(4).使用接口网关——nginx、springcloud zuul (互联网公司常规解决方案)
3.解决方案
解决方式1：响应头添加Header允许访问
跨域资源共享（CORS）Cross-Origin Resource Sharing
解决方式2：jsonp 只支持get请求不支持post请求
用法：①dataType改为jsonp ②jsonp : "jsonpCallback"————发送到后端实际为http://a.a.com/a/FromServlet?userName=644064&jsonpCallback=jQueryxxx ③后端获取get请求中的 jsonpCallback ④构造回调结构
解决方式3：httpClient内部转发
实现原理很简单，若想在B站点中通过Ajax访问A站点获取结果，固然有ajax跨域问题，但在B站点中访问B站点获取结果，不存在跨域问题，这种方式实际上是在B站点中ajax请求访问B站点的HttpClient，再通过HttpClient转发请求获取A站点的数据结果。但这种方式产生了两次请求，效率低，但内部请求，抓包工具无法分析，安全。
解决方式4：使用nginx搭建企业级接口网关方式
www.a.a.com不能直接请求www.b.b.com的内容，可以通过nginx，根据同域名，但项目名不同进行区分。什么意思呢？这么说可能有点抽象。假设我们公司域名叫www.nginxtest.com
当我们需要访问www.a.a.com通过www.nginxtest.com/A访问，并通过nginx转发到www.a.a.com
当我们需要访问www.b.b.com通过www.nginxtest.com/B访问，并通过nginx转发到www.a.a.com
我们访问公司的域名时，是"同源"的，只是项目名不同，此时项目名的作用只是为了区分，方便转发。如果你还不理解的话，先看看我是怎么进行配置的：
我们访问公司的域名时，是"同源"的，只是项目名不同，此时项目名的作用只是为了区分，方便转发。如果你还不理解的话，先看看我是怎么进行配置的：
我们访问以www.nginxtest.com开头且端口为80的网址，nginx将会进行拦截匹配，若项目名为A，则分发到a.a.com:81。实际上就是通过"同源"的域名，不同的项目名进行区分，通过nginx拦截匹配， 转发到对应的网址。整个过程，两次请求，第一次请求nginx服务器，第二次nginx服务器通过拦截匹配分发到对应的网址。
解决方式5：使用Spring Cloud zuul接口网关
云环境中每个服务自己有跨域解决方案，而网关需要做最外层的跨域解决方案.如果服务已有跨域配置网关也有，会出现*多次配置问题。
使用ZUUL配置忽略头部信息
跨域配置
原文：https://www.cnblogs.com/wangbaoping/p/wbp1124.html