Postman 之所以没有跨域问题，根本原因在于它不遵守，也不需要遵守同源策略。
跨域报错的本质是浏览器在拦截，不是服务器在拒绝
很多人有一个误区，以为跨域请求是发不出去，或者服务器拒收了。
事实恰恰相反。
一个标准的跨域流程应该是这样的：
- 浏览器确实把请求发给了服务器。
- 服务器确实处理了请求，并且把完整的响应数据发回给了浏览器。
- **关键步骤来了，**浏览器接收到响应后，会检查响应头中的 Access-Control-Allow-Origin 字段。
- 如果该字段不包含当前页面的域名，浏览器会判定为"跨域失败"，然后丢弃响应体，抛出错误。
这是一个浏览器客户端行为。数据其实已经到了本地，只是浏览器为了安全规范，拒绝把数据交给 JS 代码。
浏览器之所以要有搞一个同源策略，还是要保证用户数据安全，这是由浏览器的运行环境属性决定的。
浏览器是一个开放的沙盒环境，它每天要加载并运行来自成千上万个不同域名，不同源的 JavaScript 代码。
你打开了 http://bank.com，浏览器存下了你的银行 Cookie。
你又打开了 http://evil.com，这个网页里可能藏着一段恶意脚本，试图向 http://bank.com 发起请求。
如果没有同源策略 http://evil.com 的脚本可以直接利用浏览器里存着的 http://bank.com 的 Cookie，像银行接口发送请求，并且读取到你的余额信息。这就是严重的数据泄露。
为了防止这种情况，浏览器规定：除非 http://bank.com明确授权，否则 http://evil.com的脚本无权读取 http://bank.com的响应数据。
Postman 之所以没事是因为它的运行环境和浏览器完全不同。
Postman 本质上就是个带 GUI 的 curl，是一个纯粹的 HTTP 客户端。
它的逻辑是：你要啥 -> 我去要 -> 要到了 -> 给你看。
它不是一个用来浏览网页的软件，它不负责解析和执行来自互联网的不可信脚本。
所有的请求参数、Header、Cookie 都是开发者手动配置的，你明确知道自己在向谁发请求。
在 Postman 里，不存在A 域名的脚本去偷 B 域名数据的场景，因为它压根就没有当前域名这个概念，也就无所谓同源还是跨域。
所以后端web接口通不通，Postman 只能证明网络层和业务逻辑层没问题，至于安全层配置对不对，必须得用浏览器测。
这也就是为啥开发接口自己测试，没问题啊，一和前端联调总有奇奇怪怪的问题