HTTP请求方法详解：GET、POST、PUT、PATCH、DELETE怎么选才不踩坑？

能跑接口的人和能把接口设计对的人，差距往往就体现在“HTTP请求方法”这几个字上。我见过不少项目，后台接口一路全靠GET和POST打天下：查数据用POST，删数据也敢用POST，新增和修改更是POST一套带走。短期看接口确实都通了，可等到要加缓存、做幂等、接第三方回调、被安全扫描抓问题的时候，这些随手选的请求方法就成了第一个背锅的点。HTTP请求方法不是花架子，它是协议留给应用程序的“动作语义”，选对了，整个系统的可维护性会上一个台阶；选错了，后面全是坑。

这篇内容我打算把HTTP里常见的请求方法逐个拆开讲清楚，包括它们背后的安全语义、幂等约定、实际使用姿势，以及我在联调和排障时踩过的一些真实坑。不管你是刚入门的前端、写后端的同学，还是偶尔要抓包看接口的运维，这篇文章都适合当一份案头速查。

1. 先建立整体认知：一条HTTP请求，本质上是“动作 + 资源 + 条件”

1.1 请求行的结构决定了请求方法的位置

所有HTTP请求都能被拆成三个层次：请求行、请求头、请求体。请求行是第一个看到的字符串，格式大致是这样：

http复制POST /api/v1/users HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 42

{"name":"张三","age":28}

这里面的POST就是请求方法，/api/v1/users是请求URI，HTTP/1.1是协议版本。后面跟着的是请求头，空行之后则是请求体。整个结构可以类比成寄快递：请求方法等于你在快递单上勾选的“快递类型”，普通件、加急件、到付件对应不同的处理流程；URI等于收件地址；请求头是面单上的备注信息；请求体才是真正装进箱子里的东西。

这个类比虽然简单，但能解释很多初学者搞不清的问题：为什么GET和POST能传数据的方式不一样？因为快递类型决定了你能把东西放在哪。协议层面的请求方法不仅约定了“动词”，还天然约束了参数应该放在URL里还是放在Body里。要是非要用GET往Body里塞一堆参数，很多代理服务器和框架根本不认识，甚至在请求发出去之前就给你拦掉了。

1.2 请求方法是给语义用的，不是给服务器“看心情”用的

HTTP/1.1标准里定义了八种方法：GET、HEAD、POST、PUT、DELETE、TRACE、OPTIONS、CONNECT。后来PATCH作为补充也加入进来，成了事实上的第九种。每一种方法都约定了一种“客户端想对资源做什么”的语义。

你可能会问：服务器端完全可以无视这些语义，把它当成一种路由接头发送选择的方式。比如后端可以写一个接口，前端无论发GET还是POST都能进入同一个处理逻辑。但真要这么干，麻烦事就来了：缓存系统不认识这种自定义规则，中间网络设备不知道哪些请求可以放行，日志系统没法统计请求类型，API网关的权限策略也不知道该不该拦截。所以，遵循请求方法的标准语义，不是在伺候“洁癖”，而是在给整条链路的所有环节一个可以依赖的公共约定。

2. 五个高频请求方法拆解：GET、POST、PUT、PATCH、DELETE

2.1 GET：无脑用它读数据，但别把账号密码放在URL里

GET是最直观的方法，语义是“从服务器获取一个资源”。它的特点是安全和幂等。“安全”是指GET请求不应该改变服务器上的资源状态，你拿它读一百次列表，列表数据不应该因此被删除或新增；“幂等”是指同样一个GET请求发多少次，服务器最终的状态都是一样的。

正因为这两条特性，GET天然适合被浏览器缓存、被CDN加速、被爬虫抓取、被搜索引擎预取。实际开发里，GET也是用得最随意的一个方法。最常见的问题是有人把不该放的参数放在URL上，比如登录接口的账号密码用GET提交。URL会出现在浏览器历史、Nginx访问日志、网关访问日志、CDN回源日志里，明文密码等于裸奔了一圈。就算不考虑安全问题，URL也有长度限制，虽然各个服务器和浏览器标准不尽相同，一般到几千个字符就开始有风险了，大段文本、文件内容完全不适合放GET上。

另外还有一个小常识：GET不是绝对不能带请求体，而是协议并不建议这么做。HTTP规范没有明确禁止GET带Body，但很多框架不解析，不少代理也会主动丢弃。为了兼容性，查数据就算参数再复杂，也别指望用GET塞JSON。先问一句“参数能不能精简一点”，能精简成查询参数就尽量精简。

2.2 POST：提交数据的万能钥匙，但也是最容易被滥用的方法

POST的语义是“向指定资源提交数据，请求服务器处理”。它常用于：创建资源、提交表单、发送消息、调用RPC式的动作接口。POST不是安全方法，因为它会修改服务器状态；同时也不是幂等方法，因为连续提交两次，服务器上就可能产生两条记录。

实际开发中，POST被滥用的程度令人发指。常见错误包括：查询列表用POST、删除数据用POST、上传文件用POST，这些场景本身不算错，但如果连一个只读数据接口都用POST，浏览器和中间层就没法帮你做任何缓存。更麻烦的是，POST天然带来的“重复提交污染”。用户支付时点了一下按钮没反应，又点了一下，结果后台生成两笔订单——这种问题本质上是请求语义选择不匹配。

那什么时候用POST最合适？创建资源、执行不可幂等的动作、发起无法用简单查询参数表达的复杂请求、上传文件，这些场景POST都是合理选择。但如果你只是想读数据，请优先考虑GET；如果你想修改服务器状态，但担心重复提交造成脏数据，可以把POST与幂等键（Idempotency-Key）配合使用，或者在业务层加唯一索引和防重令牌。

2.3 PUT：整体替换资源的“定妆照”

PUT的语义是“用请求体里的内容整体替换目标资源”。它和POST最大的区别在于两点：第一，PUT通常是幂等的；第二，PUT通常需要客户端知道完整的资源表示，也就是要给出一份完整的“定妆照”。

举个例子，一个订单接口PUT /api/v1/orders/1001，请求体里必须包含订单号、用户ID、商品列表、金额、状态等所有期望保存的字段。服务器收到后，直接拿这份数据整体覆盖原来的订单。因为客户端每次都给的是完整数据，所以无论请求发送一次、两次还是十次，只要数据一样，最终落库的订单状态都一样，这就是幂等。

但在现实项目里，很多人把PUT用歪了：传一个只有部分字段的JSON，比如只传{"status":"cancelled"}，试图只改订单状态。这种用法语法上能通过，但语义上是错的，因为一旦中途出现网络问题导致请求重发，服务器会拿一份不完整的数据去覆盖完整记录，其他字段就可能被清空。部分更新这种需求，应该交给PATCH。

2.4 PATCH：部分更新资源的“化妆术”

PATCH就是为了弥补PUT“必须整体替换”的笨重而出现的。它允许客户端只发送变化的部分，服务器只更新这部分字段。比如把用户昵称从“小红”改成“阿红”，可以这样请求：

http复制PATCH /api/v1/users/10086 HTTP/1.1
Content-Type: application/json

{"nickname":"阿红"}

PATCH的使用也带来一个需要警惕的问题：它不保证幂等。看具体实现而定。如果服务器端是用“给计数器加一”这种操作来处理PATCH，重复发两次就会加两次；如果服务器端是“把字段值设置成请求里的值”，那重复发两次结果也一样。所以，网络超时重发场景下，必须和后端确认PATCH接口是否做了幂等处理，尤其涉及金额变更、库存扣减这类敏感操作。

2.5 DELETE：别只想着“删掉”，还要关心幂等和状态码

DELETE的语义很直白：删除指定资源。它被认为是幂等的，因为删除过程是“存在则删除，不存在也不会额外产生什么”。不过在实现上有个经典争议：接口第一次DELETE返回204，第二次再请求同一个URL，应该返回404还是204？

从“服务器最终状态”的角度看，第二次返回404也是一种合理的幂等表现——资源是真的不存在了。但从客户端体验上看，如果客户端只是在简单重试，第二次收到404可能会被错误地当成业务失败。更友好的做法是：如果删除目标本来就“不存在或已删除”，返回204或200，这样客户端重试逻辑就非常干净；如果你想严格区分“方法本身不对”和“资源不存在”，也可以返回404，但客户端就得把404当成一种可以接受的终态去处理。总之，DELETE接口的幂等和404，要在团队内部约定清楚，别一半接口第二次删返回204，另一半返回404，调用方会疯的。

3. 低调但实用的四个方法：HEAD、OPTIONS、TRACE、CONNECT

3.1 HEAD：和GET长得很像，但省掉了一大笔流量

HEAD和GET几乎一模一样，唯一区别是服务器返回的响应里不能包含消息体。你发一个HEAD请求，得到的是和GET相同的响应头，包含Content-Length、Content-Type、ETag、Last-Modified这些元信息，但最终的HTML或JSON内容不会被传回来。

HEAD最有价值的场景是“探测”。比如你想知道一个大文件是否存在、请求有没有权限、资源最近修改时间是什么时候、按URL判断是不是会返回404或302，直接发HEAD就能拿到结论，不用为了看一个结果就下载整个文件。我在排查Nginx静态资源缓存配置时，经常用HEAD看响应头里的缓存控制字段，几毫秒就出结果，比请求整个文件再丢弃Body高效得多。

不过要注意：不是每个框架都实现了HEAD的默认处理。有些框架会自动把GET的处理逻辑执行一遍，再在返回阶段把Body丢弃，这样效率并不高；有些接口（尤其是下载文件的接口）可能触发真实文件读取，HEAD请求也会让服务器去磁盘上把文件完整读一遍。如果你发现HEAD请求很慢，多半是后端把它处理成了“GET+丢弃Body”，而不是一套独立的轻量逻辑。

3.2 OPTIONS：CORS预检里那个“隐形面试官”

OPTIONS的语义是“询问服务器支持哪些方法”。一个典型的响应是：

http复制OPTIONS /api/v1/users HTTP/1.1
Host: example.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: content-type
Origin: https://frontend.example.com

服务器可以返回Allow: GET, POST, PUT, DELETE, OPTIONS这样的响应头，告诉客户端它支持哪些操作。在当前的前后端分离架构里，OPTIONS最广为人知的身影是“CORS预检请求”。当浏览器发现跨域请求属于复杂请求，比如请求头带了自定义字段、Content-Type是application/json、方法不是GET/HEAD/POST的时候，会先发一个OPTIONS请求去问服务器“你允不允许这个来源、这个方法、这些请求头”。只有预检通过，浏览器才会发出真正的业务请求。

实际排查跨域问题时，如果发现浏览器报CORS相关错误，第一件事就是看Network面板里有没有OPTIONS请求，以及它返回的状态码和响应头。如果OPTIONS请求压根没发出去，那是浏览器侧拦截了；如果OPTIONS请求返回了非2xx，那是服务器没配好CORS路径；如果OPTIONS返回200但缺少Access-Control-Allow-Origin、Access-Control-Allow-Methods这些响应头，那也是无效放行。

3.3 TRACE和CONNECT：一个默认被禁用，一个负责穿隧道

TRACE方法用于回显客户端发送的请求，客户端发一个TRACE，服务器原封不动把收到的请求返回给客户端。它的初衷是用于排查链路中是否有代理修改了请求，但正因为可以把请求原样弹回来，很容易被用来窃取Cookie等敏感信息，触发跨站追踪类攻击。所以现在主流服务器默认关闭TRACE，日常开发几乎用不到，面试时知道它存在、并说出“应该禁用”就够了。

CONNECT则负责建立网络隧道。HTTPS流量在通过代理时会先发一个CONNECT请求，请求行里会写成CONNECT example.com:443 HTTP/1.1，让代理和目的服务器之间建立一个通道，之后的TLS握手数据都通过这条通道透传。这也是我们常说的“正向代理”能处理HTTPS流量的原理。相比其他方法，它更像一个“连接管理工具”而不是“资源操作工具”。很多开发者在本地联调时会配置HTTP抓包工具，原理也依赖这条隧道。

4. 请求方法不能只看“能不能通”：安全、幂等和RESTful语义一起决定

4.1 把动作和资源都写进URL的方式，已经给了请求方法一记耳光

不少老项目里能看到这样的接口风格：/api/addUser、/api/deleteUser?id=1、/api/updateUser、/api/getUserList。写这种接口的人等于把请求方法想干的事全塞进了URI里，就算URI本身有一半很直观，但副作用是资源标识和操作标识混在一起，非常容易膨胀。而且因为动词混在URL里，后续任何中间层想按“方法+路径”做统一缓存策略、打印审计日志、配置权限，都没法干净地表达。

RESTful风格的核心建议很简单：把URL集中用来表示资源，把请求方法用来表示操作。比如：

text复制GET    /api/v1/users
POST   /api/v1/users
GET    /api/v1/users/{id}
PUT    /api/v1/users/{id}
PATCH  /api/v1/users/{id}
DELETE /api/v1/users/{id}

这样设计的好处是，接口数量不用随业务动作无限膨胀。用户模块里，增删改查各一种方法加上对应的URL就被覆盖了；以后如果业务扩展出“批量导入用户”这种动作，它不属于简单的资源增删改，可以单独加一条POST /api/v1/users/import。动作和方法对不上时才额外占用一个URL，不会反过来把常见操作都做成独立路径。

4.2 安全和幂等这两个概念，面试和排障时都不能含糊

关于请求方法，有两个被高频问到的概念：安全方法和幂等方法。

安全方法指“不会修改服务器状态”的方法，GET、HEAD、OPTIONS、TRACE属于安全方法。因为不会改状态，这类请求可以被爬虫预取、被浏览器缓存、被代理缓存。POST、PUT、PATCH、DELETE都不安全，因为会改变状态。

幂等方法指“客户端重复发起同样的请求，与只发一次对服务器最终状态产生的影响一致”。GET、HEAD、PUT、DELETE是幂等方法；POST不是；PATCH看实现。注意，幂等不等于响应一定相同。比如第一次DELETE删除了一笔订单，返回204；第二次再DELETE，订单已不存在，服务器即使返回404，“服务器状态的变化”仍然都是“订单不存在”，所以依然可以认为DELETE是幂等方法。这里容易混乱的点是，你把“幂等”理解成“响应码一样”，就会觉得第二次返回404太矛盾；你把“幂等”理解成“对服务器状态的影响一样”，就豁然开朗了。

4.3 GET和POST的边界，是很多人项目里最早失守的一条线

我看过太多团队，最开始还能遵守“读用GET，写用POST”，但一旦遇到需要传复杂JSON查询条件的场景，就立刻开始妥协：GET传不了复杂体，那把所有查询条件拼在URL里又太长太乱，干脆改用POST，反正后端也能解析请求体。这种妥协一次两次没问题，时间长了，接口语义就会变得没法信任，运维和中间件也无法按语义做优化。

如果真的出现“用GET无法优雅表达复杂查询”的场景，更合理的方向通常是：把部分查询条件变成URI里的资源路径或查询参数，比如GET /api/v1/orders?status=paid&page=1；条件确实复杂到必须上JSON的，可以单独设计一个“查询任务”资源，比如POST /api/v1/order-searches创建一次查询任务，返回一个查询ID，再用GET /api/v1/order-searches/{searchId}获取结果。这个模式本身也符合REST风格，还能顺便解决深分页和查询超时问题。

4.4 HTTP和HTTPS的差异，放在请求方法语境下更应该讲透

关于“HTTP和HTTPS的区别”，搜索量一直很大。站在请求方法的角度去理解，其实是这么一回事：HTTP是明文协议，请求行里的方法、路径、请求头、请求体，只要经过网络设备，都能被看到。POST、PUT、DELETE这些方法尽管承载着修改数据的动作，但放到明文HTTP里一样没有保护。HTTPS则在HTTP和TCP之间增加了一层TLS加密，让第三方只能看到“你和服务器之间建立了连接”以及大概的流量特征，而看不到具体的请求方法、路径和内容。

这也是为什么，很多接口上线时会被强制要求改成HTTPS。不是HTTP本身有多大的协议缺陷，而是中间环节太多：局域网里的抓包者、公共WiFi上的监听者、运营商的链路设备，任何一个环节都可能把明文流量读走。你用HTTPS时，就算有人截获流量，也无法直接还原出你是把某个订单DELETE掉了还是PATCH更新了。

5. 请求方法怎么选？我总结的一套“三步判断法”

5.1 从业务动作反推方法

面对一个新接口需求，我通常先问自己三个问题：

1. 这个操作是否改变了服务器上的资源状态？
2. 如果是修改，是整体替换还是部分更新？
3. 如果客户端因为网络超时重发一次，会造成灾难性后果吗？

第一个问题立刻能区分出“读请求”和“写请求”。读请求强烈建议用GET，只有GET语义才天然支持缓存、分享URL、预取等场景。写请求再往下区分：新增类和执行动作类用POST；整体覆盖用PUT；部分更新用PATCH；删除用DELETE。

第二个问题是专门用来防“PUT当PATCH用”的。后端如果拆不清整体替换和部分更新，就用更细的规则约束：请求体里包含资源所有关键字段的，用PUT；请求体里只提供需要变更的字段的，用PATCH。

第三个问题的解决方案不是说改成一个不存在的请求方法，而是说如果操作不可幂等（比如“确认支付”“创建订单”），必须配合幂等键、防重令牌、唯一索引等手段来防护。这样即使客户端网络抖动重发了，也只会处理一次。

5.2 一张表记住最常见的业务映射

这张表不是金科玉律，但它指出一个方向：请求方法一旦确定，参数该放哪、能不能缓存、会不会被重放，其实都跟着定了。设计接口前把这几个点过一遍，就能省下很多测试阶段的返工。

5.3 用curl实测一个资源化接口的完整动作序列

假设我们要设计一个简单的用户资源接口，前端想实现新增用户、查询用户、修改昵称、删除用户四个功能。用curl做一轮完整验证，会是这个套路：

bash复制# 新增用户
curl -i -X POST http://localhost:8080/api/users \
  -H "Content-Type: application/json" \
  -d '{"username":"zhangsan","age":28}'

# 查询用户列表
curl -i -X GET http://localhost:8080/api/users

# 查询单个用户
curl -i -X GET http://localhost:8080/api/users/1

# 部分修改昵称
curl -i -X PATCH http://localhost:8080/api/users/1 \
  -H "Content-Type: application/json" \
  -d '{"nickname":"阿三"}'

# 删除用户
curl -i -X DELETE http://localhost:8080/api/users/1

用-i参数能看到状态行和响应头，这是我在联调阶段必开的选项。比如新增用户如果返回201，说明语义非常明确——资源创建成功；如果返回200但响应体为空，也不算错，只是语义略弱；如果返回405 Method Not Allowed，那说明服务端根本没有实现POST对应的路由，得先从后端日志入手。

6. 高频报错与排查技巧实录：从几个常见错误看请求方法、HTTPS与状态码

6.1 “The plain HTTP request was sent to HTTPS port”代表什么

这个报错通常出现在你用HTTP协议去访问一个只开了HTTPS端口的服务。比如Nginx配置里监听的是443端口并启用了TLS，而你手滑用http://example.com访问，或者某个客户端库配置的baseURL写成了http://，这时服务端在TLS握手之前收到了明文HTTP请求，直接返回400 Bad Request，响应文本里往往写着The plain HTTP request was sent to HTTPS port。

排查思路很简单：确认访问协议是不是https://，确认客户端库有没有把baseURL写死成http://。许多.NET和Java服务还会因为内部重定向时用错了Scheme产生这类问题，需要在反向代理层设置X-Forwarded-Proto，让业务服务知道你实际通过HTTPS访问。

6.2 “HTTP Basic: Access denied”不一定是你密码错了

这个报错常见于Git、SourceTree等客户端通过HTTPS方式推送代码时。提示是The provided password or token is incorrect，但实际原因常常是：密码或Token里包含了@、/、:等特殊字符，被客户端或URL解析器错误切割了；或者系统钥匙串（凭据管理器）里缓存了旧的账号密码，导致每次都拿旧凭据去认证。

排查时，可以先在命令行里用git config --list看看有没有残留的user信息，也可以直接重新输入一次完整凭据。如果是Token方式，注意Token值开头和结尾别多复制了换行符。更推荐的做法是把远端地址改成不带账号密码的形式，让Git客户端在推送时主动弹出凭据输入框，从源头避免特殊字符被错误解析。

6.3 502 Bad Gateway：请求方法到了后端却没人接

Nginx或API网关偶尔会返回502 Bad Gateway，这句话的意思是网关把请求转发到了上游服务，但上游没有给出合法响应。常见原因有三种：上游Java/Python服务进程挂掉或正在重启；上游服务端口拥堵，处理超时；上游应用本身触发了Worker崩溃，导致连接被异常断开。

遇到502时，我会先把完整请求复制出来，直接发给上游服务的地址试试，比如curl -i http://127.0.0.1:8080/...。如果直连也不通，问题大概率出在上游服务本身或它的宿主环境；如果直连正常，那问题可能出在网关的转发配置、超时参数或负载均衡策略上。有人说“502应该是后端自己日志里报了‘Worker terminated’”，这种情况多半是内存溢出或触发了某个框架的安全退出机制。

6.4 403 Forbidden、CSRF crumb和Docker API报错

不少人在Jenkins调Docker API或配置Harbor时见过这种报错：HTTP 403 Forbidden，响应里还有一句no valid crumb was included in the request。这其实是Jenkins的CSRF防护机制在起作用：它要求每次请求除了正常的Cookie，还必须带上一个crumb字段，否则拒绝执行。这种情况不是HTTP协议本身的问题，而是目标应用在请求头上强制附加了自己的安全校验。

处理思路：不要只盯着HTTP状态码，403和401的区别要分清。401是“你没认证或认证失败”，403是“服务端认识你，但你不满足访问条件”。排查时先确认是否登录、Cookie是否有效，再确认应用有没有要求额外的CSRF Token或请求头签名。这类问题用API文档或抓包对比最有效。

结尾

我在实际联调里感受最深的一点是：请求方法这件事，越早形成统一规范，后期省的事越多。它不是后端自己拍脑袋定的，也不是前端想用什么就用什么，而是整个团队对一个接口“在协议层面扮演什么角色”达成共识。与其等接口上线后才发现缓存加不上、重复提交没人管、跨域被OPTIONS卡住，不如新接口设计的第一天就把方法、幂等、语义、状态码这四件事定下来。至于PATCH和PUT怎么分、POST要不要配防重、TRACE要不要关，这些问题看似零碎，但每一个都对应着线上真实会踩的坑。把这张网先织好，后面做缓存、做网关、做安全审计时，你都会感谢当初那个认真选请求方法的自己。