RFC规范解释、URL 与 Body 、GET/POST 的核心区别详解
很多开发者对 GET 和 POST 的认知，可能还停留在 “参数写 URL 里还是 Body 里” 的表层区别 —— 但这俩 HTTP 请求方法的差异，远不止这么简单。
从 RFC 规范的底层语义，到 “安全 / 幂等” 的核心属性，再到实际开发里的踩坑案例，今天我们顺着逻辑一层层拆，把 GET 和 POST 的区别讲透。
一、先锚定底层：RFC 规范里，GET 是 “读”，POST 是 “写”
要搞懂 GET 和 POST 的区别，得先回到 HTTP 的 “官方说明书”——RFC 规范。这两个方法的语义定义，是所有差异的根源：
GET：“只读” 的资源获取者
RFC 给 GET 的定位很明确：向服务器请求指定的资源，比如打开一篇文章、加载一张图片、拉取商品列表。
它的参数通常拼接在 URL 里，这也带来了两个限制：
- 因为 URL 的基础字符集是 ASCII，中文等非 ASCII 字符不能直接放（得通过 URL 编码转成 ASCII）；
- 浏览器会对 URL 长度做限制（HTTP 协议本身没限制，但浏览器有自己的规则）。
典型场景很好识别：你打开一篇公众号文章、刷新网页、在搜索框输入关键词点击搜索，用的都是 GET。
POST：“读写” 的资源操作者
而 POST 在 RFC 里的定义是：通过请求的 Body（报文负载），对服务器的资源做处理—— 比如新增一条留言、提交一份表单、创建一笔订单。
它的数据会放在 Body 中，这也让它更灵活：
- Body 支持任意格式的数据（只要客户端和服务器提前协商好）；
- 浏览器不会对 Body 的大小做限制，适合传大文件、复杂数据。
典型场景比如：你在文章末尾写了留言点 “提交”、上传头像、下单支付，用的都是 POST。
二、基于语义的 “性格差异”：安全 & 幂等
明确了 GET 和 POST 的语义之后，RFC 还给它们规定了两个核心属性 ——“安全” 和 “幂等”，这才是两者最本质的 “性格区别”。
先把这两个概念说清楚：
- 安全：指请求不会 “破坏” 服务器资源 —— 简单说就是 “只读不写”，不会新增、修改、删除数据；
- 幂等：指多次执行相同的请求，服务器最终的结果是一致的。
GET：天生安全 + 幂等
因为 GET 的语义是 “只读”：
- 无论你请求多少次，服务器里的资源都不会被修改（符合 “安全” 的定义）；
- 每次请求返回的结果也完全一样（符合 “幂等” 的定义）。
这也是为什么：
- 浏览器会自动缓存 GET 请求（比如重复打开同一篇文章，直接读本地缓存，不用再发请求）；
- GET 请求可以存为书签、直接分享链接 —— 毕竟怎么点结果都一样。
POST：不安全 + 不幂等
而 POST 的语义是 “写操作”：
- 提交一次就会修改服务器资源（比如留言会新增一条数据，不符合 “安全”）；
- 多次提交会产生多个结果（比如重复点 “提交订单”，会创建多笔交易，不符合 “幂等”）。
这也是为什么：
- 浏览器不会缓存 POST 请求 —— 毕竟每次提交都可能改数据；
- 刷新 POST 请求的页面时，浏览器会弹 “是否重新提交” 的提示 —— 怕你重复操作搞出问题。
踩坑预警：别乱改语义！
这里要提个实际开发里的反面案例：
有人用 GET 实现了 “删除博客” 的接口 —— 结果 Google 的爬虫把他的博客链接爬了一遍，相当于自动执行了多次 “删除” 请求，最后所有博客都被删光了。
RFC 的规范是 “建议”，但违背语义用方法，很容易踩这种哭笑不得的坑。
三、几个容易搞混的认知误区
了解了核心逻辑，再聊聊实际开发里常遇到的 “认知坑”—— 这些都是从语义和属性延伸出来的细节：
误区 1：GET 请求不能加 Body？
RFC 规范没禁止 GET 带 Body，但从 “获取资源” 的语义来说，完全没必要 —— 而且大部分开发框架（比如 Spring、Node.js）默认不支持解析 GET 请求的 Body，强行加会导致数据丢了都查不到原因。
误区 2：GET 的 URL 里不能放中文？
不是 “不能放”，是 “不能直接放”：
URL 的基础字符集是 ASCII，中文属于非 ASCII 字符，直接放会导致乱码。但可以通过 URL 编码（百分号编码） 把中文转成 ASCII 字符（比如 “你” 会转成%E4%BD%A0），浏览器和框架会自动帮你完成编码和解码。
误区 3：POST 的 URL 里不能加参数？
可以加！只是习惯把数据放在 Body 里—— 比如http://xxx.com/submit?type=1，这里的type=1就是 POST 请求的 URL 参数，服务器一样能正常解析。
四、开发里的最佳实践：按规则用，少踩坑
最后给几个实际开发里的建议，帮你避开这些方法的 “雷区”：
- 严格按语义选方法：查数据、获取资源用 GET；提交、修改、删除数据用 POST；
- 敏感数据别用 GET：URL 会留在浏览器历史、服务器日志里，容易泄露（但 HTTP 本身是明文，真敏感的数据必须用 HTTPS）；
- 利用 GET 的缓存提效：对不常变的资源（比如静态图片、文章内容），用 GET 的缓存机制减少服务器压力。
总结
GET 和 POST 的核心区别，从来不是 “参数放 URL 还是 Body”—— 而是RFC 定义的语义，以及由此延伸出的 “安全 / 幂等” 属性。
按规范用对方法，不仅能避免像 “爬虫删博客” 这样的坑，还能让接口更符合互联网的设计逻辑，既安全又高效。
