当浏览器变成“醋坛子”

想象一下：你开了一家奶茶店（前端页面），想从隔壁面包房（后端服务器）偷师学艺。结果刚探头，浏览器保安就一把拦住：“不行！你俩不是一个老板（域名），不准串门！”——这就是著名的跨域问题。今天我们就用奶茶店的例子，拆解跨域背后的三大“协议/方案”：CORS、JSONP和反向代理，顺便吐槽它们的奇葩操作。

第一章 跨域的本质：浏览器的“被迫害妄想症”

关键词解释：跨域（Cross-Origin）的本质是浏览器出于安全考虑，用同源策略（Same-Origin Policy）封锁了不同域名、端口或协议间的数据交互。

举个栗子🌰：

- 你的网站 `https://www.nihaocha.com` 想请求 `https://api.xiaomianbao.com` 的数据。

- 浏览器：“域名对不上？端口都是443但协议不同？统统算跨域！”（是的，连 `http` 和 `https` 都算不同源！）

专业吐槽：

> “同源策略就像个过度操心的老妈，生怕你吃了隔壁家的饼干会中毒。”

第二章 解决方案一：CORS——官方“通行证”协议

CORS（Cross-Origin Resource Sharing） 是W3C官方推荐的跨域方案，核心是让服务器在响应头里加一句：“这我小弟，放行！”

CORS实战演示

假设面包房的API支持CORS，它会在响应头里塞这些“暗号”：

```http

Access-Control-Allow-Origin: https://www.nihaocha.com

Access-Control-Allow-Methods: GET, POST

Access-Control-Allow-Headers: Content-Type

```

浏览器看到后：“哦豁，有授权？那通过吧！”

坑爹时刻💥

1. 简单请求 vs 预检请求：

- GET/POST不带自定义头？直接发（简单请求）。

- 用了PUT或自定义头？先发个OPTIONS预检请求探路，像极了面试前先问HR：“你们接受996吗？”

2. 带Cookie的傲娇要求：

如果想传Cookie，前后端都得设参数：

```javascript

// 前端：axios配置

withCredentials: true

```

```http

// 后端响应头

Access-Control-Allow-Credentials: true

第三章 解决方案二：JSONP——穿越时空的“漏洞”

如果CORS是正规签证，那JSONP就是钻狗洞——利用 `

3. 后端返回一段JS代码直接调用该函数：

drinkTea({ recipe: "波霸+奶茶+糖" }); // 前端自动执行！

致命缺点❌

- 只支持GET请求（你想用POST传秘方？没门！）。

- 安全性堪忧：万一回调函数被注入恶意代码……恭喜，你的奶茶店变黑客窝点。

> “JSONP就像用信鸽传秘密配方——轻便但可能被老鹰截胡。”

第四章 解决方案三：反向代理——伪装成“自己人”

不想折腾CORS头？那就让后端大哥（Nginx/Node.js）帮你“套马甲”！

Nginx反向代理配置示例

```nginx

location /api/ {

proxy_pass https://api.xiaomianbao.com/;

偷偷转发请求

proxy_set_header Host api.xiaomianbao.com;

伪装成面包房员工

}

```

此时前端直接请求 `/api/getRecipe`，浏览器以为在访问同源地址，实际Nginx在背后暗度陈仓。

适用场景🎯

- 前后端分离项目（比如Vue+Spring Boot）。

- 需要隐藏真实API地址（防止被竞争对手分析）。

第五章 终极对比表：三大方案谁是你的菜？

| 方案 | 优点 | 缺点 | 适用场景 |

||--|-|--|

| CORS | W3C标准、支持所有HTTP方法 | 需要后端配合改Header | 现代Web应用 |

| JSONP | 兼容古董浏览器 | 仅GET、安全性差 | IE8等老旧系统 |

| 反向代理| 前端无需改动 | 增加服务器复杂度 | DevOps友好的项目 |

：没有完美方案，只有合适的选择

选跨域方案就像选奶茶配料：CORS是标准珍珠奶茶（稳妥但步骤多），JSONP是路边摊椰果（快捷但风险高），反向代理是隐藏菜单（灵活但要技术力）。下次遇到跨域问题时，记得大喊一声：“老板，我要加CORS头！”

TAG:服务器跨域是什么协议,服务器跨域是什么协议类型,跨域服务器代理,服务器跨域是什么协议的