去年有个数据挺有意思——Stack Overflow上关于"Failed to Fetch"的提问，47%最终都指向同一个罪魁祸首。不是代码写错了，不是API挂了，而是一个叫CORS的东西。
更扎心的是，同样的请求在Postman里跑得飞快，一到浏览器就原地爆炸。这种"开发环境正常，生产环境翻车"的玄学，消耗了无数程序员的发量。
问题根源藏在浏览器的一个安全机制里：同源策略（Same-Origin Policy）。
浏览器把"同源"定义得很死：协议、域名、端口，三个要素必须完全一致。你的前端跑在http://127.0.0.1:5500，想请求https://youtube.com的接口？门儿没有。
CORS（跨域资源共享）就是用来协商这种"跨界合作"的。但协商有个前提：对方服务器得在响应头里写上Access-Control-Allow-Origin，明确说"我允许你来"。YouTube显然不会给随便一个本地页面开这个绿灯。
于是浏览器先发一个预检请求（preflight）探路，服务器没给通行证，请求直接被拦腰斩断。报错信息往往云山雾罩，新手看到"Failed to Fetch"四个字，第一反应是检查网络连接。
复现现场：一个注定要失败的Demo
GitHub上有个教学项目，专门用来演示这个坑。克隆下来，VS Code里点"Go Live"，一个简陋的YouTube视频信息抓取页就跑起来了。
输入框里贴个视频链接，点击Fetch Info，按钮转两圈，然后——报错。控制台里红字刺眼，网络面板却干干净净，仿佛请求从未存在过。
这就是CERR的典型症状：请求被浏览器内部拦截，根本没发出去。你在Network标签页里看不到它，因为拦截发生在请求离开浏览器之前。
很多开发者在这里卡壳数小时，试图用mode: 'no-cors'蒙混过关，结果拿到一个opaque响应，啥数据也读不出来。这选项的真实作用是"我放弃读取响应"，而非"绕过限制"。
浏览器的安全设计就是这样：要么服务器配合，要么你换个思路。
代理模式：把跨域变成"内部事务"
既然浏览器不让直接问YouTube，那就找个"自己人"代劳。代理服务器的核心逻辑很简单：前端只跟同源的服务器说话，服务器再去跟外部API打交道。
服务器之间没有同源策略，curl和Postman能成功的原因正在于此。代理就是把"服务器端自由"借给前端用。
具体实现上，Node.js搭个Express服务，前端请求/api/video-info?url=xxx，服务器收到后用自己的HTTP库（如axios）去抓YouTube页面，解析完把数据吐回去。全程没有跨域，浏览器挑不出毛病。
代码结构会变成这样：
proxy-version/
├── index.html # 还是原来的页面
├── styles.css # 样式不动
├── app.js # 改请求地址为相对路径
└── server.js # 新增的代理服务
前端代码的改动极小，把fetch('https://youtube.com/...')换成fetch('/api/video-info?url=...')即可。剩下的脏活累活，服务器默默承担。
生产环境的延伸思考
本地开发用代理很爽，但部署到线上怎么办？Vercel、Netlify这些平台都提供serverless函数，本质上还是代理模式的变体。你的"代理"跑在CDN边缘节点，延迟比自建服务器更低。
还有一种思路是配置反向代理，Nginx里写几行规则，把/api/*转发到目标服务器。这招对第三方API特别管用，还能顺便做缓存和限流。
但代理不是万能药。它引入了新的故障点——代理服务器挂了，前端照样抓瞎。还有数据隐私问题：用户把YouTube链接发给你的服务器，你得保证不滥用。
有些团队为了省事，直接把第三方API的密钥塞进前端代码，让代理带着密钥去请求。这等于把钥匙挂在门把手上，抓包就能拿走。
更稳妥的做法是：前端只传用户输入，密钥和签名逻辑全在服务器完成。
回到那个Demo项目，修复后的版本能正常抓取视频标题、缩略图和观看次数。同样的功能，差了一个代理层，体验天差地别。
很多前端框架的dev server都内置了代理配置，Vue的vue.config.js、React的setupProxy.js，本质上都是这个原理。开发时自动转发，部署时再换正式方案。
理解了代理模式，再看这些配置就不会觉得魔幻。它们不是框架的黑魔法，而是CORS约束下的必然选择。
那个YouTube Info项目的作者在后记里写了一段话：「我花了整整一个下午调试CORS，最后发现是浏览器在保护我。这种保护有时候像过度热心的保安——不分青红皂白拦下所有人，包括你自己。」
你最近一次被CORS拦住是什么时候？当时选了代理方案，还是说服后端改了响应头？
热门跟贴