一、HTTP 是什么
你在浏览器地址栏输入 www.example.com，然后回车。
这一瞬间发生了什么？
简单说：浏览器通过 HTTP 协议，向服务器"要"了一份网页数据，然后显示给你看。
HTTP，全称 HyperText Transfer Protocol（超文本传输协议），它是互联网通信的"语言"。
你可以把它想象成"快递协议"——浏览器是寄件人，服务器是收件人，HTTP 就是规定快递怎么寄、怎么收、怎么确认的规则。
二、HTTP 长什么样
2.1 一次完整的 HTTP 请求
当你打开一个网页，浏览器其实在后台发了一段"对话"：
浏览器（请求）：
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Chrome/120.0
Accept: text/html服务器（响应）：
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
<html>
<body>Hello World</body>
</html>拆解一下：
| 部分 | 说明 |
| --- | --- |
| GET | 请求方式：我要"获取"数据 |
| /index.html | 请求的资源路径 |
| HTTP/1.1 | 协议版本 |
| Host | 我要访问哪个网站 |
| 200 OK | 响应状态码：成功了 |
| Content-Type | 返回的数据类型是 HTML |
| <html>...</html> | 真正的内容 |
2.2 常见请求方式
| 方式 | 含义 | 典型场景 |
| --- | --- | --- |
| GET | 获取数据 | 打开网页、搜索、查询列表 |
| POST | 提交数据 | 登录、注册、发评论 |
| PUT | 更新数据（整体替换） | 修改用户信息 |
| PATCH | 更新数据（局部修改） | 只改用户昵称 |
| DELETE | 删除数据 | 删除一条记录 |
2.3 常见状态码
| 状态码 | 含义 | 新人理解 |
| --- | --- | --- |
| 200 | 成功 | 一切正常 |
| 301 | 永久重定向 | 页面搬家了，去新地址 |
| 302 | 临时重定向 | 暂时去别的地方 |
| 400 | 请求错误 | 你发的东西有问题 |
| 401 | 未授权 | 请先登录 |
| 403 | 禁止访问 | 你没权限看这个 |
| 404 | 找不到 | 页面不存在 |
| 500 | 服务器内部错误 | 服务器自己炸了 |
新人记住：看到 4xx 是你的问题，看到 5xx 是服务器的问题。
三、HTTP vs HTTPS
3.1 核心区别：一个"S"的差距
| | HTTP | HTTPS |
| --- | --- | --- |
| 全称 | HyperText Transfer Protocol | HTTP + Secure |
| 端口 | 80 | 443 |
| 加密 | 明文传输 | SSL/TLS 加密传输 |
| 证书 | 不需要 | 需要 CA 机构颁发的证书 |
| 安全性 | 低 | 高 |
| 浏览器标识 | ⚠"不安全" | 小锁图标 |
3.2 为什么 HTTPS 更安全
HTTP 就像寄明信片——路上谁都能看到你写了什么。
HTTP: 浏览器 ——"我的密码是123456"——→ 服务器
↑
黑客也能看到！HTTPS 就像寄密封信——只有收件人能拆开看。
HTTPS: 浏览器 ——"一堆乱码&*#@!"——→ 服务器（只有服务器能解密）
↑
黑客看到的是乱码，没用3.3 HTTPS 的工作流程（简化版）
1. 浏览器说："我要安全连接"
2. 服务器把"身份证"（证书）发给浏览器
3. 浏览器验证证书是不是真的
4. 双方协商一个"暗号"（加密算法）
5. 之后所有数据都用这个暗号加密传输3.4 什么时候用 HTTP，什么时候用 HTTPS
| 场景 | 推荐 | 原因 |
| --- | --- | --- |
| 生产环境（正式上线） | 必须 HTTPS | 用户数据安全，浏览器也强制要求 |
| 登录、支付、个人信息页面 | 必须 HTTPS | 密码、银行卡不能明文 |
| 企业内部系统 | 建议 HTTPS | 内网也有被监听的风险 |
| 本地开发（localhost） | HTTP 即可 | 本机调试不需要加密 |
| 纯静态展示页面（无用户数据） | HTTP 也行 | 但现在搜索引擎更喜欢 HTTPS |
| 任何需要传输敏感数据的场景 | 绝对不能用 HTTP | 等于裸奔 |
记住一条铁律：2024 年以后，Chrome 浏览器会对所有 HTTP 页面标记"不安全"。所以，能用 HTTPS 就用 HTTPS。
四、跨域问题 —— 新人最常踩的坑
4.1 什么是"同源"
浏览器有一个安全规则叫 同源策略（Same-Origin Policy）。
判断是否"同源"，看三样东西：
| 条件 | 说明 |
| --- | --- |
| 协议相同 | 都是 http 或都是 https |
| 域名相同 | 都是 example.com |
| 端口相同 | 都是 80 或都是 443 |
三个都相同 = 同源 = 可以随意通信
任何一个不同 = 跨域 = 浏览器会拦截！
举几个例子：
当前页面：https://www.example.com:443/page
√ 同源：https://www.example.com:443/api （全相同）
× 跨域：http://www.example.com:443/api （协议不同）
× 跨域：https://api.example.com/api （域名不同）
× 跨域：https://www.example.com:8080/api （端口不同）
× 跨域：https://www.other.com/api （域名不同）4.2 为什么要有同源策略
防止恶意网站偷你的数据。
假设你登录了银行网站 A，然后不小心打开了恶意网站 B
如果没有同源策略：
网站B 可以偷偷发请求到银行A，用你的身份转账！
有了同源策略：
网站B 的请求会被浏览器拦截 → 你的钱保住了4.3 跨域长什么样 —— 报错信息
你在开发时最常看到的报错：
Access to XMLHttpRequest at 'http://api.example.com/users'
from origin 'http://localhost:3000' has been blocked by
CORS policy: No 'Access-Control-Allow-Origin' header is
present on the requested resource.翻译成人话：
"你从 localhost:3000 想访问 api.example.com 的数据，但服务器没说允许你访问，浏览器替你拦下来了。"
4.4 什么时候会遇到跨域
前端开发中最典型的场景：
前端项目跑在：http://localhost:3000（或 www.mysite.com）
后端API在： http://localhost:8080（或 api.mysite.com）
↑ 域名或端口不一样 → 跨域！4.5 怎么解决跨域
方案一：后端配置 CORS（最常用、最推荐）
CORS（Cross-Origin Resource Sharing，跨域资源共享） 是后端告诉浏览器："我允许这个来源访问我。"
后端需要在响应头里加：
Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization如果你用 Node.js（Express），加一行代码就行：
const cors = require('cors');
app.use(cors()); // 允许所有来源（开发用）
// 或指定来源（生产用）
app.use(cors({
origin: 'https://www.mysite.com'
}));方案二：开发环境用代理（前端配置）
在开发阶段，可以让前端的构建工具帮你"转发"请求：
Vite 配置（vite.config.js）：
export default {
server: {
proxy: {
'/api': {
target: 'http://localhost:8080', // 后端地址
changeOrigin: true,
rewrite: (path) => path.replace(/^\/api/, '')
}
}
}
}这样前端请求 /api/users，实际被转发到 http://localhost:8080/users，浏览器认为是同源的。
方案三：Nginx 反向代理（生产环境）
生产环境通常用 Nginx 做反向代理，把前端和后端"藏"在同一个域名下：
server {
listen 80;
server_name www.mysite.com;
# 前端静态资源
location / {
root /usr/share/nginx/html;
}
# 后端API转发
location /api/ {
proxy_pass http://localhost:8080/;
}
}浏览器访问的都是 www.mysite.com，同源策略就不会触发。
4.6 跨域解决方案对比
| 方案 | 适用场景 | 谁来配置 |
| --- | --- | --- |
| 后端 CORS | 所有场景，最根本的解法 | 后端开发 |
| 开发代理（Vite/Webpack） | 本地开发调试 | 前端配置 |
| Nginx 反向代理 | 生产环境部署 | 运维/后端 |
新人记住：跨域不是前端的 bug，是浏览器的安全机制。解决方案大多在后端或服务器配置层面。
五、HTTP 的其他重要概念（快速了解）
5.1 Cookie —— 浏览器的"记忆"
服务器可以让浏览器"记住"一些信息：
Set-Cookie: userId=123; HttpOnly; Secure浏览器下次请求会自动带上这个 Cookie
HttpOnly：JS 读不到，防 XSS
Secure：只在 HTTPS 下发送
5.2 Token（JWT）—— 现在更流行的认证方式
Cookie 有跨域和 CSRF 风险，现在主流用 Token：
登录成功后，服务器返回：
{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}
前端把 token 存起来（localStorage 或 memory）
每次请求带上：
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...5.3 Keep-Alive —— 连接复用
HTTP/1.0 每次请求都要重新建立连接（握手），HTTP/1.1 可以复用连接，快很多。
HTTP/1.0: 握手 → 请求 → 响应 → 断开 → 握手 → 请求 → 响应 → 断开
HTTP/1.1: 握手 → 请求 → 响应 → 请求 → 响应 → 请求 → 响应 → 断开六、一张图总结
┌─────────────────────────────────────────────────────┐
│ HTTP 协议 │
│ │
│ ┌──────────┐ 请求/响应 ┌──────────┐ │
│ │ 浏览器 │ ←────────────→ │ 服务器 │ │
│ │ (前端) │ 明文(HTTP) │ (后端) │ │
│ │ │ 加密(HTTPS) │ │ │
│ └──────────┘ └──────────┘ │
│ │
│ 跨域：域名/端口/协议不同 → 浏览器拦截 │
│ 解决：CORS / 代理 / Nginx │
│ │
│ 认证：Cookie → Token(JWT) │
└─────────────────────────────────────────────────────┘