说起来，

前后端通信不是魔法，是 HTTP 协议、数据格式和浏览器安全机制共同演奏的交响曲

先看全貌的观点是。一次请求的旅程

浏览器 网络 服务器
① 构造HTTP请求报文 DNS解析 → 路由转发
|
② 服务器解析请求
③ 返回HTTP响应报文 |
④ 浏览器接收响应 |
⑤ 检查同源策略/CORS |
⑥ JS解析响应体 → 更新DOM

看起来简单，但 ①③⑤ 三步藏着 Web 开发 % 的“坑”。下面逐一拆解，

至于第一乐章，HTTP 报文——前后端的“通用语言”

请求报文

POST /api/login HTTP/1.1
Host的观点是，localhost
Content-Type: application/json
Authorization: Bearer eyJhbGci...
Cookie的观点是，sessionId=abc123
再看Origin，http://localhost
{"username":"张三","password":"123456"}

四个关键请求头。记住它们：

🔍 你可能没想过的问题：fetch里的 URL 去哪了？

当你写 fetch 时浏览器会自动拆分这个 URL：

完整 URL：https://api.example.com/data
├─ 协议 https:// → 用于建立 TLS 加密连接
├─ 域名 api.example.com → 放进请求头 Host:
├─ 方法 /data → 放进请求行
└─ 端口 → 用于 TCP 连接

实际发出的 HTTP 报文：

GET /data HTTP/1.1
说到Host。api.example.com
User-Agent: Mozilla/...
Accept这方面，application/json
至于Origin，http://localhost

响应报文

HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: http://localhost
Set-Cookie: sessionId=xyz789;HttpOnly

{"status":"ok","data":{"name":"张三"}}

状态码速记——面试和日常开发最常遇到的：

// 简化示意，非真实源码
Response.prototype.json = async function {
const text = await this.text;// 第一步先：解码
return JSON.parse;// 接下来：解析
}，