不管是前端同窗仍是后端同窗，可能都接触过跨域问题。网上已经有了不少介绍跨域问题和解决方案的博客文章，笔者以前也是看过不少关于跨域问题的文章，当时感受已经了解得差很少了，不过最近又有了一些新的认识，因此写这篇文章记录一下，但愿也能对读者有所帮助。固然，本文是笔者本身的认识和实践，若是有不许确的地方，还请不吝指教。html
在正式介绍以前，你们能够先思考一下下面几个问题：前端
一、跨域问题是浏览器致使的仍是服务端致使的？python
二、为何在服务端配置几个响应头就能够解决跨域问题？segmentfault
三、发生跨域问题时，请求发送出去了没有？服务端有没有接收到请求，有没有进行处理和响应？后端
四、为何在浏览器里发送Ajax请求会发生跨域，可是在浏览器地址栏直接请求接口或者经过postman却不会有问题？跨域
五、跨域问题（或者说背后的同源策略）到底保护的是谁？浏览器
这几个问题是笔者最近从新认识或者是从新确认的问题。本文主要是围绕上面的几个问题展开的，对于一些基础知识（如同源策略等）则不会赘述，还请你们自行百度。安全
对于问题1，你们应该都知道答案——浏览器，具体来讲是浏览器同源策略的限制。post
既然是浏览器的限制，那浏览器限制的是什么，请求仍是响应？最开始笔者也是认为是限制了请求，跨域问题发生的时候，浏览器拦截了请求，没有发送出去。可是这种理解没法解释问题2，若是请求没有发送出去，也就是请求根本就没有到达服务端，服务端的配置又有什么用呢？测试
实际上，浏览器限制的是响应。
这个问题也比较容易验证，读者能够在本地启动一个服务端测试接口，用来接收前端页面的请求（设置断点或者打印日志来确认请求是否接收成功），好比接口地址为：http://localhost:8080/test，而后再写一个前端页面，经过 Ajax 方式请求后端接口，须要保证前端页面的访问也是经过域名访问的（比较简单的方式是使用 python -m SimpleHTTPServer 8000），好比访问地址是：http://localhost:8000/test.html。最终的结果证实，发生跨域报错时，请求已经发送出去了，并且服务端接收了请求而且进行了正常的处理。
确认了限制响应这个问题，那么问题2和问题3就迎刃而解了。
对于问题4，其实也容易理解。你们能够回到“同源”和“跨域”这两个词自己，对于直接发出的请求，不管是从浏览器的地址栏发出的请求，仍是 postman 发出的请求，仍是 Java 程序发出的请求，根本没有当前域的概念，实际上每发出一个请求，都是在独立请求一个资源，而不是在一个网站返回的页面里，再去请求另一个网站/端口的资源，天然也就不会形成跨域了。
对于问题5，实际上是要解释限制响应这种方式，对于服务端来讲是没有保护做用的。要解释这个问题，仍是要回到同源策略，这是浏览器的安全策略，虽然也是要保护用户的数据，可是是从浏览器的角度出发的。简单说是要浏览器保证在A域名下谨慎接收B域名返回的资源，防止B域名返回的资源是窃取A域名用户数据的恶意资源，这种保护只是最基础的保护机制（也能够说是最弱的保护），你不能期望同源策略来彻底保护用户数据。对于用户数据的保护，主要工做仍是在服务端完成，服务端要保证请求是合法的、是已经鉴权的。
以上即是读者最近关于跨域问题的新认识。
在这里提一下，同源策略是一个很是核心、很是基础的策略，是 Web 前端安全的核心，网上有人说，
《Web前端黑客技术揭秘》，很是系统的解析了前端安全知识，这些知识都是要围绕着同源策略展开的，可想而知它是有多重要
对于同源策略的理解，当前也只是停留在大概是什么、大概能解决什么问题的阶段，对于理解跨域问题已经基本足够，可是对于具体的场景仍是理解很少，但愿往后能有机会再整理一篇关于同源策略的深度文章，可能那时候对于跨域也会有更深的理解。
参考文章：
浏览器的同源策略
https://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy
浏览器同源政策及其规避方法，阮一峰
http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html
不要再问我跨域的问题了