1. 核心特性对比
| 维度 | GET | POST |
|---|---|---|
| 语义 | 获取数据（幂等操作） | 提交数据（非幂等操作） |
| 参数位置 | URL查询字符串（?key=value） | 请求体（Body） |
| 数据长度限制 | 受URL长度限制（通常2KB~8KB，因浏览器/服务器而异） | 无明确限制（适合传输大文件或表单数据） |
| 安全性 | 参数明文暴露在URL中（易被缓存、日志记录） | 参数在请求体中（相对安全，但仍需HTTPS加密） |
| 缓存 | 可被浏览器缓存 | 默认不可缓存 |
| 历史记录 | 保留在浏览器历史记录中 | 不保留 |
| 书签 | 可收藏为书签（含参数） | 不可收藏 |
| 编码类型 | 仅支持URL编码（application/x-www-form-urlencoded） | 支持多种编码（如multipart/form-data、JSON） |
| 幂等性 | 幂等（多次请求结果相同） | 非幂等（多次请求可能产生副作用） |
2. 使用场景
| 方法 | 典型场景 | 示例 |
|---|---|---|
| GET | - 获取资源（如搜索、分页） - 无副作用的操作 - 数据可公开或非敏感 | GET /api/users?page=2 获取用户列表第二页数据 |
| POST | - 提交表单或文件 - 创建资源（如新增订单） - 敏感数据操作（如登录、支付） | POST /api/login 提交用户名密码；POST /api/upload 上传文件 |
3. 技术细节
-
幂等性：
GET的幂等性使其适合重复请求（如刷新页面），而POST重复提交可能导致重复创建资源（需后端防重处理）。 -
性能：
GET请求可以被CDN或浏览器缓存，减少服务器压力；POST每次需服务端处理。 -
RESTful API规范：
- GET对应查询（Read）
- POST对应创建（Create）
（注：实际开发中可能不严格遵循，但语义清晰利于协作）
4. 安全性误区
- GET“不安全” ：
参数在URL中暴露，易被浏览器历史、服务器日志记录，但安全性最终取决于是否使用HTTPS。
示例：GET传密码（错误）→ 即使HTTPS加密，URL中的密码仍可能被泄露。 - POST“绝对安全” ：
请求体数据仍可被抓包工具截获，敏感数据（如密码）需结合HTTPS和加密传输。
5. 面试回答技巧
- 简明回答：
“GET用于获取数据，参数在URL中，可缓存且幂等；POST用于提交数据，参数在请求体中，适合敏感或大数据传输。” - 结合场景：
“在实现搜索功能时用GET，参数暴露便于分享链接；提交订单时用POST，避免重复下单和参数泄露。” - 深入扩展：
“从RESTful角度，GET对应Read，POST对应Create；实际开发中还可通过请求头区分语义（如X-HTTP-Method-Override）。”
