1、核心区别：语义与设计目的 (RFC 规范)
-
GET - 获取资源
- 语义：从服务器获取指定资源（幂等操作）。
- 设计场景：查询数据、页面跳转、静态资源加载（如 HTML/CSS/JS）。
- 面试点：强调其安全性（Safe） 和幂等性（Idempotent） （多次调用结果相同）。
-
POST - 提交数据
- 语义：向服务器提交数据，可能修改资源状态（非幂等）。
- 设计场景：表单提交、文件上传、创建新资源（如用户注册）。
- 面试点：强调其非幂等性（多次调用可能产生副作用，如重复下单）。
2、技术实现差异（前端视角）
| 特性 | GET | POST |
|---|---|---|
| 数据位置 | URL 查询字符串（?key=value） | 请求体（Request Body） |
| 数据长度限制 | 受 URL 长度限制（约 2KB~8KB） | 理论上无限制（服务器可配置限制） |
| 数据可见性 | 暴露在 URL、浏览器历史、日志中 | 在请求体中，相对隐蔽 |
| 缓存 | 可被缓存、书签保存 | 默认不可缓存，除非在响应头中包含适当的Cache-Control或Expires字段。 |
| 浏览器回退 | 无害（幂等） | 会提示重新提交（非幂等） |
| Content-Type | 通常无请求体 | 需指定（如 application/json） |
2.1、GET请求的缓存原理：为什么静态资源会被缓存，而查询接口可能不会
-
GET请求默认支持缓存：HTTP协议中，GET请求的设计是幂等的（即多次请求不会改变资源状态），因此它们可以被浏览器或中间代理（如CDN）缓存缓存机制包括ETag、Last-Modified等响应头，用于标识资源版本。当浏览器首次GET静态资源时，会缓存响应；后续请求时，检查缓存头，如果资源未变，则直接从缓存加载。
-
浏览器差异导致查询接口不被缓存：
-
Chrome和Firefox的浏览器策略：默认只缓存静态资源（如JS、CSS、图片文件），因为它们通常不频繁变化。但对API查询接口（如获取数据的GET请求），浏览器可能不缓存，因为这些数据可能实时更新。
- 浏览器会根据请求头识别是否是静态资源，比如请求的文件后缀、
Content-Type资源类型都是识别的依据
- 浏览器会根据请求头识别是否是静态资源，比如请求的文件后缀、
-
IE浏览器策略：会缓存所有GET请求（包括查询接口），这可能带来数据不一致问题（如新增数据后，缓存返回旧数据。
-
3、安全性误区（重点！）
-
GET 不等于不安全，POST 不等于安全
- GET 参数暴露在 URL 中，容易被嗅探或记录，但不代表 POST 绝对安全。
- 真正安全的传输需依赖 HTTPS（防止中间人攻击）。
- 敏感操作（如转账）必须用 POST + CSRF Token，避免通过 URL 触发。
4、面试延伸问题（务必准备！）
-
为什么 POST 更适合提交敏感数据？
- 答：GET 参数暴露在 URL 和服务器日志中，易被泄露；POST 数据在请求体中，且 HTTPS 下可加密传输。
-
GET 请求能传 JSON 吗？
- 答：技术上可以（将 JSON 字符串 URL 编码后放在
?data=参数中），但违反设计原则。应使用 POST 传递结构化数据。
- 答：技术上可以（将 JSON 字符串 URL 编码后放在
-
POST 比 GET 更耗性能吗？
- 答：否。请求性能主要取决于数据量和网络，与请求方法无关。但 POST 常伴随较大请求体，可能影响速度。
-
如何实现幂等的 POST 请求？
- 答：服务端设计时通过唯一 Token（如订单ID）保证多次提交仅生效一次，常用于支付系统。
5、RESTful API 中的使用规范
- GET → 获取资源（
/users） - POST → 创建资源（
/users） - PUT/PATCH → 更新资源（
/users/1） - DELETE → 删除资源（
/users/1）
面试点：错误使用 GET 创建资源（如
GET /create-user?name=Bob）违反 REST 设计原则。
6、总结
“GET 用于获取数据，参数在 URL 中，幂等且可缓存；POST 用于提交数据，参数在请求体中，非幂等且更适合敏感操作。但安全性最终依赖 HTTPS，而非请求方法本身。”
