GET 和 POST 的区别：别只背参数位置

GET 和 POST 的区别很容易被背成一句话：GET 参数在 URL，POST 参数在请求体。这样记不算错，但太薄了。文中最后也强调，GET 和 POST 本质上都是 HTTP 请求协议里的请求方法，HTTP 又基于 TCP/IP 通信。很多差异来自 HTTP 语义、浏览器行为、服务器实现和使用约定。

GET 常用于申请获取资源，不希望对服务器资源产生影响。POST 常用于提交数据，例如提交表单、上传文件、创建资源或更新资源。真正设计接口时，先看“这次操作想表达什么语义”，再考虑参数放在哪里。

所以这篇不只列区别表。我们会从语义、请求报文、参数位置、安全和幂等、缓存、浏览器行为、编码方式和排查顺序几个角度讲。这样以后遇到接口问题，不会只盯 URL 上有没有参数。

GET 的语义是获取资源。比如打开文章详情页、搜索列表、读取用户资料，通常都适合 GET。它表达的是“请把这个资源给我”，不应该因为多请求几次就改变服务器上的数据。

POST 的语义是提交数据。注册账号、提交订单、上传文件、保存表单、发评论，这些操作通常会改变服务器资源，或者触发服务器创建新数据。文中也写到，POST 会影响服务器，服务器可能动态创建新的资源或更新原有资源。

语义不是装饰，它会影响缓存、重试、浏览器回退、网关处理和团队协作。一个明显会改数据的操作如果做成 GET，短期看能跑，长期很容易出问题。

GET 的参数通常放在 URL 查询字符串里，例如 `GET /search?keyword=network&page=1 HTTP/1.1`。这样做的好处是直观，链接可以复制、收藏、分享，也方便浏览器和缓存系统识别同一个资源。

POST 的参数通常放在请求体里。请求行只写路径，例如 `POST /users HTTP/1.1`，请求头里写 `Content-Type: application/json`，空行后面的请求体里再放 JSON、表单或文件内容。上一篇讲请求报文时提到，请求体通常在 POST、PUT 等请求中使用，这里正好接上。

要注意，HTTP 协议本身并没有简单规定“GET 一定不能有请求体”或“URL 只能多长”。实际限制多来自浏览器、服务器、代理和框架。文中提到 URL 长度限制更多是浏览器和服务器原因，这个说法更准确。日常开发不要把实现限制误认为协议本身。

HTTP 语义里的“安全”，不是加密安全，而是指请求方法不会破坏服务器资源。GET 通常被认为是安全的，因为它是只读操作。你刷新一次搜索页，理论上不应该创建新订单、扣库存或修改用户资料。

幂等指多次执行相同操作，结果应该一样。GET 通常也是幂等的，多次读取同一资源，不应该改变资源本身。POST 常用于新增或提交数据，多次提交可能创建多条记录，所以通常不是幂等的。

这也是为什么浏览器回退或刷新 POST 表单时，经常会提示是否重新提交。它担心你重复提交数据。GET 回退通常更自然，因为再次获取同一个资源一般不会造成副作用。

文中提到，GET 请求会被浏览器主动 cache，如果下一次请求的数据相同，可以返回缓存内容；POST 默认不会这样，除非手动设置。这个说法放在日常理解里是有帮助的：GET 更容易参与浏览器缓存和中间缓存，POST 更偏向一次提交。

GET 的参数会完整保留在浏览器历史记录里，也可以被保存为书签。比如搜索页 URL 里带 `keyword=network`，你复制链接给别人，对方打开后能看到同样查询条件。这对列表筛选、分页、搜索很方便。

POST 的参数通常在请求体里，不会直接出现在地址栏，也不适合保存为书签。表单提交、支付、登录这类动作如果被浏览器随便缓存或收藏，反而危险。

很多人会把“GET 参数在 URL 可见”理解成 GET 不安全，把“POST 参数在请求体”理解成 POST 安全。这不准确。GET 的参数确实更容易出现在地址栏、日志、历史记录和分享链接里，所以不适合放密码、Token 等敏感信息。但 POST 请求体如果走明文 HTTP，同样可能被窃听。

真正保护传输内容，要靠 HTTPS。HTTPS 会把 HTTP 报文放进 TLS 加密通道里，不只是保护 POST 请求体，也会保护路径之外的大部分请求内容。域名本身、连接目标、一些握手信息仍然有自己的暴露边界，HTTPS 专题后面会单独讲。

接口设计时，可以简单记：敏感信息不要放 URL；需要传输保护就用 HTTPS；需要鉴权就正确使用 Cookie、Authorization 或其他认证机制。不要把 POST 当成安全方案。

文中提到一种常见说法：GET 产生一个 TCP 数据包，POST 可能先发 Header，服务器响应 `100 Continue`，再发送 data，最后服务器返回 200。这个描述能帮助理解 `Expect: 100-continue` 场景，但不适合机械套到所有请求上。

实际网络传输会受到浏览器、协议版本、请求体大小、TCP 分段、TLS、代理和服务器行为影响。GET 和 POST 都只是 HTTP 方法，不应该简单理解成固定几个 TCP 包。上一些网络面试题会这么问，但回答时最好补一句：这是某些实现或特定场景下的表现，不是 GET/POST 的本质区别。

GET 和 POST 的本质差异，还是语义、请求报文使用方式、缓存和浏览器行为。不要为了背一个 TCP 包数量，把主要问题讲偏。

第一，看接口文档要求的方法。文档写 POST，实际发 GET，服务器可能返回 404、405、400，也可能被网关拦截。第二，看参数位置。GET 参数是否在查询字符串，POST 请求体是否真的带出去了。

第三，看 `Content-Type`。POST 传 JSON，就确认是不是 `application/json`；提交普通表单，就看是不是 `application/x-www-form-urlencoded`；上传文件，就看是不是 `multipart/form-data`。请求体格式和 Content-Type 不一致，是请求排查里很常见的问题。

第四，看认证和缓存。GET 请求可能被缓存，导致你看到的不是最新结果；POST 请求如果缺少 Cookie 或 Authorization，可能被重定向到登录页，或者返回 401、403。方法、URL、头部、请求体要一起看，单独看一个字段很容易误判。

可以这样答：GET 和 POST 都是 HTTP 请求方法。GET 语义上用于获取资源，通常安全且幂等，参数常放在 URL 查询字符串里，容易被缓存、收藏和保留在历史记录中。POST 语义上用于提交数据，常把参数放在请求体里，可用于表单、JSON、文件上传等场景，通常会改变服务器资源，所以一般不是安全幂等的。

然后补一句：参数位置和长度限制并不是 HTTP 协议本身最核心的区别，很多限制来自浏览器、服务器和框架实现。安全性也不能简单说 POST 比 GET 安全，敏感信息不应放 URL，传输加密要依赖 HTTPS。

这样回答比“GET 参数在 URL，POST 参数在 body”更稳。它既保留了常见差异，也避免把经验规则说成协议铁律。