HTTP 请求方法速查（安全与幂等语义）

5 个速查板块 · 关联 5 款站内工具 · 数据最后核对 2026-10-05

GET 和 POST 到底差在哪、PUT 与 PATCH 该怎么选、哪些方法可以放心重试——按「安全 / 幂等 / 有无请求体」三个维度一次理清。

HTTP 方法（也叫请求方法、HTTP 动词）决定「这次请求想对资源做什么」。表面上只是几个英文单词，实际却带着两套重要约定：安全（safe）表示不改动服务端数据，幂等（idempotent）表示重复执行一次和多次的结果相同。这两条约定不是学术名词——重试策略、爬虫行为、缓存策略都建立在它们之上。

实际开发中真正容易出错的是两组对照：GET 与 POST 的边界（尤其是「查询用 GET、提交用 POST」背后的原因），以及 PUT 与 PATCH 的选择（整体替换还是局部更新）。下面先给全量方法对照表，再逐组辨析。

快速跳转 九个标准方法总览 GET 与 POST：不只是「一个在 URL 一个在 body」 PUT 与 PATCH：整体替换还是局部修改 重试与预检：幂等性在工程上的用处 方法与方法之外：该配哪个状态码

1九个标准方法总览

先看三个维度：是否安全（不改数据）、是否幂等（重复执行结果一致）、是否常规带请求体。这三列定下来，选方法就没什么可纠结的了。

方法用途安全幂等请求体
GET获取资源，参数放在 URL是是语义未定义，不应使用
HEAD只取响应头，不要响应体是是无
POST提交数据、创建资源、触发处理否否有
PUT整体替换目标资源否是有
PATCH局部修改目标资源否一般否有
DELETE删除目标资源否是语义未定义
OPTIONS查询该资源支持的方法与跨域预检是是一般无
TRACE回显收到的请求，用于诊断是是无
CONNECT建立隧道（如经代理访问 HTTPS）否否无

「安全」不等于「没有副作用」：GET 也可以在服务端记日志、加计数。安全方法只承诺「不改变被请求资源所代表的数据」，所以爬虫和预取器可以放心地发 GET，却绝不该自动发 POST。

2GET 与 POST：不只是「一个在 URL 一个在 body」

两者最深层的区别在语义，其次才是形式。理解了这个顺序，很多「什么该用哪个」的争论会自然消失。

对比项GETPOST
语义获取资源，不改变服务端状态提交数据，通常会改变服务端状态
参数位置查询字符串（URL 的一部分）请求体
可缓存默认可缓存默认不缓存（除非显式声明新鲜度）
可收藏 / 可分享可以，URL 自带全部参数不可以，参数在请求体里
浏览器后退 / 刷新安全，不会重复提交会提示「是否重新提交表单」
幂等性幂等不幂等
长度限制受 URL 长度与服务器缓冲区限制受服务端请求体大小限制，通常宽松得多
安全性参数明文留在 URL 与历史记录里参数在请求体中，但仍是明文（必须靠 HTTPS）

常见误区是「POST 比 GET 安全」。两者在传输层都是明文，真正保护数据的是 HTTPS，不是方法本身。GET 的唯一真实弱点是参数会留在浏览器历史、代理日志和 Referer 里。

3PUT 与 PATCH：整体替换还是局部修改

这一组的关键词是「替换」。PUT 的语义是「用我给你的这份完整资源覆盖掉旧的」，PATCH 的语义是「按我给的这份差异描述改一改」。语义不同，后果也不同。

对比项PUTPATCH
语义整体替换：没提到的字段会被清空或恢复默认局部修改：只改提到的字段
请求体内容资源的完整新状态一份差异描述（具体格式由接口自行约定）
幂等是，重复 PUT 同一份数据结果一致规范上不保证；实现为「字段赋值」时通常幂等
适用场景配置整体保存、文件覆盖上传改一个昵称、调一个状态位
常见坑只想改一个字段却用了 PUT，其余字段被清空并发场景下靠差异描述容易覆盖别人的修改

4重试与预检：幂等性在工程上的用处

幂等不是一个抽象概念，它直接决定「网络抖了一下之后，客户端敢不敢自动重发」。这是前后端协作里最实用的一条规则。

可以安全重试
GET、HEAD、PUT、DELETE、OPTIONS——服务端应当保证重复执行的效果与执行一次相同，网上常见的「幂等重试」默认只对这些方法生效
不该盲目重试
POST、PATCH——重发可能创建两条记录、扣两次款。需要重试的支付类操作应改用「幂等键」（请求头带一个唯一 ID，服务端据此去重）
OPTIONS 预检
跨域且属于非简单请求时，浏览器会先发一次 OPTIONS，服务端必须返回 2xx 与正确的 Access-Control-Allow-* 头，真实请求才会发出
HEAD 的用途
检查资源是否存在、看文件大小与修改时间、探测重定向，而不必下载整个文件。响应头必须与对应的 GET 一致，只是没有响应体
只允许 GET/POST 的环境
部分老旧代理或网关会拦掉其它方法，此时会用 X-HTTP-Method-Override 之类的自定义头把真实方法带过去。这是兼容手段，不是标准
TRACE 通常被关闭
因为它会原样回显请求内容，可能被用来实施跨站追踪攻击，多数生产服务器默认禁用

5方法与方法之外：该配哪个状态码

方法与状态码是配套的。选对了方法却返回一个不匹配的状态码，会让接口语义变得难以理解。

操作方法常见成功状态码
查询列表或详情GET200（无结果时返回空数组，而不是 404）
新建资源POST201 并带 Location 指向新资源
更新成功且有返回内容PUT / PATCH200
更新成功但无需返回内容PUT / PATCH204
删除成功DELETE204（或 200 带结果说明）
地址存在但方法不支持任意405，并在 Allow 响应头里列出支持的方法

看完就能用的站内工具

全部工具总览 →
站长工具
HTTP 状态码查询

在线查询 HTTP 状态码含义与常见成因，覆盖 1xx-5xx 共 60+ 常见状态码，支持关键词搜索与分类筛选，纯浏览器本地处理
编程开发
curl命令生成器

在线生成curl命令，支持GET/POST/PUT/DELETE等方法，自定义Header、Body、认证（Basic/Bearer/API Key），纯本地处理
站长工具
缓存头Cache-Control生成器

生成 Cache-Control 响应头，支持 public 与 private、max-age、s-maxage、immutable、must-revalidate 等指令，附常用资源类型的缓存天数换算。
站长工具
重定向链与循环检测器

在线检测 URL 重定向链条的跳数、跨域跳转与循环死循环，输出最终落地 URL 与逐跳明细
编程开发
WebSocket测试

在线WebSocket客户端，连接测试、消息收发、实时调试，支持ws/wss协议

关于「HTTP 请求方法速查（安全与幂等语义）」的常见问题

GET 和 POST 最本质的区别是什么？

是语义，不是参数位置。GET 的语义是「取回资源，不改变服务端状态」，所以它可以被缓存、被收藏、被预取、被安全地重复发送；POST 的语义是「提交数据去处理」，通常会改变服务端状态，因此默认不缓存、不可收藏、刷新时会提示重复提交，也不能盲目重试。参数放在 URL 还是请求体只是这层语义带来的形式差异——理解了语义，形式上的选择自然就定下来了。

PUT 和 PATCH 该用哪个？

看你想表达「替换」还是「修改」。PUT 的语义是用请求体里的完整资源覆盖目标资源，所以没提到的字段会被清空或恢复默认值，接口文档里必须写清「全部字段都要传」。PATCH 只改请求体里提到的字段，适合改昵称、调状态这类局部更新。实践中最常见的错误是「只想改一个字段却用了 PUT」，结果把其它字段一起抹掉了。

哪些请求可以自动重试？

按规范，只要方法幂等，就允许在超时或连接中断后重发：GET、HEAD、PUT、DELETE、OPTIONS 都属于这一类。POST 和 PATCH 不保证幂等，盲目重试可能创建重复订单、重复扣款。需要重试的非幂等操作，通常的做法是在请求头里带一个由客户端生成的唯一请求 ID（幂等键），服务端记录并识别重复请求，第二次直接返回首次的结果。

为什么跨域请求会先发一个 OPTIONS？

因为浏览器要先确认服务端是否允许这次跨域。当请求不属于「简单请求」（例如使用了 PUT、DELETE 方法，或带了自定义请求头，或 Content-Type 是 application/json）时，浏览器会先发一个 OPTIONS 预检请求，把真实请求要用的方法和请求头列出来问服务端。服务端必须返回 2xx 并在 Access-Control-Allow-Methods / Allow-Headers 里明确放行，真实请求才会发出——预检不通过，业务代码根本没有执行的机会。

继续查：相关内容

全部速查 →
HTTP 状态码速查表 HTTP 请求头与响应头速查 URL 结构与百分号编码速查 选型指南：SEO 与安全自查工具怎么选 场景合集：site-launch
内容标识：本页内容由人工智能辅助生成，并经人工核对与编辑。详见 人工智能生成内容标识说明。
内容说明：本页速查数据由本站自行整理，事实性内容以对应官方规范与文档为准，未复制第三方速查表或百科的表述。数据最后核对日期：2026-10-05。若发现错误或已更新的标准，欢迎通过页脚反馈入口告知。