每个 HTTP 请求的开头都有一句动词——GET、POST、PUT、DELETE——它告诉服务器这次访问的性质；代理IP链路里调试接口，第一眼看的往往就是这组动词：是单纯取内容，还是要提交数据。这一组动词就是 HTTP 方法，也叫请求方法，是请求里最先被读取的语义信号。
方法的选择直接决定服务器怎么处理请求：用对了方法，一次请求干净利落；用错了方法，轻则行为不符，重则请求被拒。代理IP场景调试接口时，方法写错是最高频的入门错误之一，值得一次认全。
这篇把方法家族的主要成员逐个认识：每个方法干什么、什么时候用、常见误解有哪些。
| 方法 | 语义 | 典型场景 | 容易混淆的点 |
|---|---|---|---|
| GET | 取内容 | 打开网页、加载图片 | 不该带请求体 |
| POST | 提交新数据 | 登录、发帖、下单 | 与 PUT 界限模糊 |
| PUT | 整体更新 | 替换整份资源 | 与 POST 混用常见 |
| DELETE | 删除 | 删除资源 | 需谨慎权限设计 |
| HEAD | 只要头 | 探测资源是否存在 | 与 GET 结果相同 |
| OPTIONS | 问能力 | 跨域预检等场景 | 日常较少直接遇到 |
表格里的六种方法覆盖了绝大多数场景，其中 GET 与 POST 是绝对主力：浏览网页几乎全是 GET，提交操作几乎全是 POST。认熟这两个，日常使用就够；其余方法在代理IP接口联调与开发调试时才会频繁露面。
方法与语义的边界
方法背后有两条约定值得记住：GET 只该取数据、不该改变服务器状态——所以「删除操作却用 GET 实现」是设计上的坏味道；POST 与 PUT 都用于写数据，但 POST 偏向新建、PUT 偏向整体替换，接口设计时按语义选用。
还有一类容易被忽略的方法级细节：有些代理与服务器对非常见方法支持不佳，遇到「方法不支持」类报错时，先确认对方允许哪些方法，再回头检查自己用的是否在列——代理IP链路里这个排查顺序尤其管用。
方法说完了请求的性质，就该看服务器的答复了：每次响应开头那三个数字——状态码——是服务器对请求最精炼的回应，下一篇看状态码五族地图。
HTTP 方法是一组动词：GET 取、POST 建、PUT 改、DELETE 删——请求的性质由它定义，方法与语义匹配才不会出错。
方法之外的请求细节
方法只定义了请求的性质，请求的具体细节由 URL 与请求头补充：URL 里的路径指明对哪个资源操作，查询参数带上操作所需的变量。方法、路径、参数三者合起来，才是一次请求的完整语义——代理IP场景里抓包分析一次请求，看的就是这三要素的组合。
方法家族里还有一个值得知道的冷知识：不是所有方法都安全。GET 与 HEAD 被设计为只读操作，可以放心重复；POST 与 DELETE 等则会改变数据，重复执行可能造成重复提交或误删——接口设计里对「幂等性」的讨论，正是围绕这些方法的语义展开的。
方法的选择还有一个经验之谈：拿不准该用哪个时，优先用语义最贴近的那个——只读用 GET、提交用 POST，其余方法在明确需要时再用。语义清晰的方法选择，不仅让服务器处理正确，也让协同开发的同事和未来的自己更容易读懂请求意图；代理IP接口联调时，方法选对能让排查事半功倍，代理链路对方法的支持差异也常在联调时暴露。