一、HTTP 是什么？
-
定义 ：超文本传输协议（HyperText Transfer Protocol），应用层协议，基于 TCP（默认端口 80；HTTPS 为 443 + TLS 加密）。
-
核心特点：
- 无状态：每次请求独立，服务器不保留上下文（通过 Cookie/Session 模拟状态）。
- 请求-响应模型：客户端发起请求 → 服务器返回响应。
- 明文传输（HTTP）：敏感数据需用 HTTPS（HTTP + SSL/TLS）。
- 版本演进：HTTP/1.1（当前最广泛）、HTTP/2（多路复用、头部压缩）、HTTP/3（基于 QUIC）。初学建议先吃透 HTTP/1.1。
-
为什么重要：所有 Web 通信（API、网页、文件上传等）的底层规则，后端需精准处理请求/响应。
二、常见 HTTP 状态码（按类别精要）
| 类别 | 状态码 | 含义 | 后端使用场景 |
|---|---|---|---|
| 2xx 成功 | 200 OK | 请求成功 | 普通查询返回 |
| 201 Created | 资源创建成功 | POST 创建资源后返回，含 Location 头 |
|
| 204 No Content | 成功但无响应体 | DELETE 操作后常用 | |
| 3xx 重定向 | 301 Moved Permanently | 永久重定向 | 域名迁移 |
| 302 Found | 临时重定向 | 登录后跳转（注意：POST 重定向可能转为 GET） | |
| 304 Not Modified | 缓存有效（配合 If-Modified-Since） |
优化性能，减少传输 | |
| 307/308 | 临时/永久重定向（保持原请求方法） | 比 302/301 更符合 REST 语义 | |
| 4xx 客户端错误 | 400 Bad Request | 请求语法错误 | 参数校验失败 |
| 401 Unauthorized | 未认证（需登录） | 返回 WWW-Authenticate 头 |
|
| 403 Forbidden | 无权限访问 | 权限校验失败 | |
| 404 Not Found | 资源不存在 | 路径错误或资源删除 | |
| 405 Method Not Allowed | 方法不支持 | 如对只读接口发 POST | |
| 429 Too Many Requests | 请求过频 | 限流场景 | |
| 5xx 服务器错误 | 500 Internal Server Error | 服务器内部错误 | 代码异常（需日志排查） |
| 502 Bad Gateway | 网关错误（上游服务异常） | Nginx 代理后端挂掉 | |
| 503 Service Unavailable | 服务暂不可用 | 维护中或过载 | |
| 504 Gateway Timeout | 网关超时 | 后端服务响应慢 |
💡 提示：RESTful API 设计中，状态码是语义的重要组成部分（如创建用 201，删除用 204）。
三、常见 HTTP 头字段（Header）
| 类型 | 字段 | 作用 | 示例/注意 |
|---|---|---|---|
| 请求头 | Host |
HTTP/1.1 必需，指定目标域名（支持虚拟主机） | Host: api.example.com |
User-Agent |
客户端标识（浏览器/爬虫） | 用于兼容性处理 | |
Accept |
客户端可接受的响应类型 | Accept: application/json |
|
Content-Type |
请求体格式（POST/PUT 关键） | application/json, multipart/form-data |
|
Authorization |
认证凭证（Bearer Token / Basic） | Bearer xxx |
|
Cookie |
客户端携带的会话标识 | 由 Set-Cookie 设置 |
|
Referer |
请求来源页面 | 防盗链、统计 | |
| 响应头 | Content-Type |
响应体格式 | text/html; charset=utf-8 |
Set-Cookie |
服务器设置客户端 Cookie | 含 HttpOnly, Secure 等属性 |
|
Location |
重定向目标地址（配合 3xx） | Location: /new-path |
|
Cache-Control |
缓存策略 | max-age=3600, no-cache |
|
WWW-Authenticate |
401 时要求认证方式 | Basic realm="Access" |
|
| 通用头 | Date |
消息生成时间 | 服务器自动添加 |
Connection |
连接管理（HTTP/1.1 默认 keep-alive） |
🔒 安全提示 ：敏感头（如
Authorization）务必通过 HTTPS 传输；Set-Cookie建议加Secure（仅 HTTPS）、HttpOnly（防 XSS）。
四、GET vs POST：本质区别与常见误区
| 维度 | GET | POST |
|---|---|---|
| 语义（RFC 核心） | 安全 + 幂等：仅获取资源，不修改服务器状态 | 非安全 + 非幂等：提交数据，可能创建/修改资源 |
| 参数位置 | URL 查询字符串（?id=1） |
请求体（Body），格式由 Content-Type 决定 |
| 缓存/书签 | 可缓存、可收藏为书签 | 默认不缓存（需显式设置），不可直接书签 |
| 浏览器行为 | 回退无提示 | 回退时提示"重新提交表单" |
| 数据类型 | 仅 ASCII（需 URL 编码） | 支持二进制（如文件上传） |
| 长度限制 | 受浏览器/服务器 URL 长度限制（非协议规定） | 无协议限制（但服务器可配置 body 大小） |
| 幂等性 | ✅ 多次请求效果相同 | ❌ 多次提交可能产生副作用（如重复下单） |
⚠️ 澄清常见误区：
-
"POST 比 GET 安全" → 错误！
- 安全性取决于是否用 HTTPS。GET 参数在 URL 中易泄露（历史记录、日志），故敏感数据（密码、token）绝不放 URL，但 POST Body 同样可被截获。
- HTTP 术语中"安全"指"不改变服务器状态"，GET 是安全方法，POST 不是。
-
"GET 不能有 Body" → 不严谨
- HTTP/1.1 未禁止 GET 带 Body，但语义上强烈不推荐，且多数服务器/代理会忽略或报错。
-
"POST 一定发两个 TCP 包" → 谣言
- 数据包数量取决于实现、网络状况，与方法无关（HTTP/1.1 可 Pipeline，HTTP/2 多路复用）。
✅ 后端实践建议：
-
遵循语义：查询用 GET，创建用 POST，更新用 PUT/PATCH，删除用 DELETE（RESTful）。
-
防误用 ：绝不使用 GET 执行修改操作（如
?action=delete&id=1），易被 CSRF 攻击或爬虫触发。 -
参数设计：
- GET：用于过滤、分页（
/users?role=admin&page=2） - POST：提交表单、上传文件、发送 JSON（
Content-Type: application/json）
- GET：用于过滤、分页（