同一个请求，为什么Postman可以，浏览器却报错？

前言

作为一个前端开发者，你一定经历过这样的"至暗时刻"：

接口文档写得清清楚楚，后端信誓旦旦说"我这边没问题"，你满怀信心地在浏览器里发起请求，然后——

Access to XMLHttpRequest at 'xxx' from origin 'xxx' has been blocked by CORS policy...

那一瞬间，屏幕前的你和屏幕里的报错，大眼瞪小眼。

"又是跨域！"你心里默默骂了一句。

跨域问题，堪称前端开发的"老朋友"了。网上关于如何解决跨域的文章汗牛充栋，什么CORS配置、代理服务器、JSONP……方法一大堆。但今天我想聊的不是"怎么解决"，而是怎么思考。

因为比起记住十种解决方案，掌握一种思维方式显然更有价值。

正文

一个有趣的现象：Postman的"特权"

故事要从一次调试说起。

某天，我在开发一个功能，需要调用一个第三方API。按照惯例，我先用Postman测试了一下接口——完美，数据返回得漂漂亮亮。

于是我信心满满地把代码写进项目里，在浏览器中运行，然后……

CORS error

"？？？"

同样的接口，同样的参数，同样的请求方式。Postman那边岁月静好，浏览器这边风起云涌。

如果你也遇到过类似的情况，恭喜你，你已经站在了理解跨域本质的门槛上。

触类旁通：从现象倒推本质

这里我想分享一个非常实用的思维方式——从现象倒推结论，也就是所谓的"触类旁通"。

我们来梳理一下已知信息：

请求是一样的，服务器是一样的，唯一的变量是发起请求的工具。

那么结论几乎是显而易见的：

跨域限制，是浏览器的行为，而非服务器的行为。

这个结论看似简单，但它揭示了一个很多人忽略的事实：服务器其实是正常返回了响应的！只不过浏览器基于安全策略，"好心"地帮你拦截了而已。

换句话说，跨域不是"请求发不出去"，而是"响应被浏览器扣下了"。

顺藤摸瓜：浏览器既然能限制，就应该能解除

想通了上面这一点，下一步推理就顺理成章了：

既然跨域限制是浏览器主动加上的"枷锁"，那浏览器自己应该也有办法解开这个枷锁吧？

带着这个猜测，我打开搜索引擎，输入关键词："Chrome 关闭跨域"

果不其然，答案就在那里等着我。

Chrome提供了一个启动参数，可以禁用同源策略：

# macOS
open -n -a /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --args --disable-web-security --user-data-dir=/tmp/chrome_dev

# Windows
chrome.exe --disable-web-security --user-data-dir=C:\temp\chrome_dev

启动后，你会看到浏览器顶部出现一个醒目的黄色警告条："您使用的是不受支持的命令行标记：--disable-web-security"。

这时候再去请求那个跨域接口，神奇的事情发生了——畅通无阻。

当然，这种方式仅适用于开发调试，千万不要在日常浏览时使用，否则你的浏览器就相当于在裸奔，任何网站都可以随意读取其他网站的数据。

解决跨域的"武器库"又多了一件

到这里，我们通过一次简单的观察和推理，就自主发现了一种新的跨域解决方案。

让我们更新一下解决跨域问题的"武器库"：

1. 1. 后端配置CORS响应头 —— 最正规的做法
2. 2. 代理服务器转发 —— 前端最常用的开发手段
3. 3. JSONP —— 古老但有时有效
4. 4. Nginx反向代理 —— 生产环境常见方案
5. 5. 浏览器禁用同源策略 —— 开发调试的"作弊码"（新增！）

每多掌握一种方法，你在面对跨域问题时就多一分从容。

这种思维方式的价值

其实今天真正想和大家分享的，不是"Chrome怎么关闭跨域"这个知识点——这个你搜一下就能找到。

我想分享的是这种思考问题的方式：

1. 1. 观察现象：Postman可以，浏览器不行
2. 2. 分析变量：唯一的区别是请求发起方
3. 3. 得出结论：限制来自浏览器
4. 4. 延伸推理：浏览器应该能解除限制
5. 5. 验证猜测：搜索求证

这套思维模式，适用于几乎所有技术问题的排查。

遇到bug时，与其漫无目的地搜索"xxx报错怎么解决"，不如先冷静下来，观察现象，分析变量，缩小范围，定位本质。

很多时候，答案就藏在那些"反常"的现象里。

结语

计算机世界里的很多知识，并不需要死记硬背。

当你理解了原理，很多解决方案其实可以自己"推导"出来。就像今天这个例子，我们没有查任何文档，仅仅通过观察Postman和浏览器的不同表现，就自主发现了跨域的本质，并由此找到了一种新的解决方案。

这就是触类旁通的力量。

下次当你遇到技术问题时，不妨先停下来问自己：

• • 这个问题在其他环境下会发生吗？
• • 是什么变量导致了不同的结果？
• • 从这个现象，我能推导出什么结论？

毕竟，授人以鱼不如授人以渔。

记住十种解决方案，不如掌握一种思考方式。