poxiaoxi博客打开网页、搜索关键词、提交登录表单、发表评论，这些操作背后都会产生HTTP请求。其中GET和POST是最常见的两种请求方法。
很多人简单地把它们理解成“GET参数显示在网址中，POST参数隐藏起来”。这种说法能帮助入门，但并不完整。GET和POST真正的区别，首先在于它们表达的请求语义不同。
GET主要用于获取数据
GET通常表示从服务器读取或查询资源。
例如搜索网站：
https://example.com/search?q=seo&page=2
其中：
q=seo page=2
属于URL查询参数，也就是Query String。
常见GET场景包括：
打开文章和产品页面；
搜索关键词；
分类筛选；
分页；
查询数据。
GET在HTTP语义上属于安全方法，客户端请求的目的应该是读取数据，而不是要求服务器修改业务状态。
POST主要用于提交数据
POST通常用于向服务器提交数据，并让服务器进一步处理。
例如登录请求可能是：
POST /login username=test password=123456
浏览器地址栏可能仍然只显示：
https://example.com/login
用户名和密码等数据通常位于Request Body，也就是请求体中。
POST常见于：
登录和注册；
发表评论；
提交订单；
上传文件；
提交复杂表单；
调用需要创建或处理数据的接口。
两者主要区别
| 区别 | GET | POST |
|---|---|---|
| 主要用途 | 获取、查询数据 | 提交和处理数据 |
| 参数常见位置 | URL查询字符串 | Request Body |
| 是否方便分享URL | 方便 | 不能仅靠URL还原Body |
| 缓存 | 通常更容易缓存 | 需要满足特定条件才可缓存 |
| HTTP安全语义 | 安全 | 非安全 |
| 幂等性 | 幂等 | 不保证幂等 |
| 典型场景 | 搜索、分页、读取 | 登录、提交、创建 |
POST也可以带URL参数
网址中出现参数，并不能直接判断请求一定是GET。
例如：
POST /article?id=123 title=新的标题 content=新的正文
这个POST请求同时存在：
URL参数： id=123 请求Body： title content
因此：
URL中有 ?id=123 ≠ 一定是GET请求
真正判断请求类型，需要查看HTTP Request Method。
在Chrome开发者工具中可以进入：
F12 → Network → 选择请求 → Headers → Request Method
POST并不天然更安全
“POST参数不显示在地址栏，所以POST更安全”是一个常见误区。
POST Body虽然不会直接显示在网址中，但仍然可以被浏览器开发者工具、服务器程序和网络调试工具读取。
真正保护传输内容的是HTTPS。
尤其是密码、Token和个人敏感信息，不适合直接放入GET查询参数，因为URL还可能出现在：
浏览器历史记录；
服务器访问日志；
代理和监控系统；
复制分享的链接。
登录等敏感操作通常采用HTTPS配合POST，而不是单纯依靠POST本身保证安全。
GET为什么适合搜索和分页
Google、Bing和百度的普通网页搜索都能看到类似URL：
Google： /search?q=SEO Bing： /search?q=SEO 百度： /s?wd=SEO
使用GET后，查询条件可以直接保留在URL中。
用户可以复制：
/search?q=foobar2000&page=2
其他人打开后仍然能够进入相同查询条件下的页面。
因此搜索、筛选和分页等需要形成稳定URL的功能，通常更适合GET。
GET不适合执行危险操作
下面这种设计并不合理：
GET /delete-user?id=123
因为GET按照HTTP语义应该用于读取数据。浏览器预加载、搜索爬虫、安全扫描程序或者用户误点链接，都可能触发这个地址。
删除、付款、修改密码、提交订单等会改变业务状态的操作，不应该设计成一个普通GET链接即可执行。
GET和POST的数据量也有差别
GET参数通常放在URL中，而浏览器、Web服务器、CDN和代理服务都可能对URL长度设置限制。
因此下面这些简单参数比较适合GET：
keyword=seo page=2 sort=date
而大量JSON、长文章内容和文件上传等数据，更适合通过POST请求体发送。
HTTP规范本身不能简单理解成“GET最多只能传多少KB”，实际限制取决于整个请求链路中的软件和服务配置。
POST重复提交要特别注意
GET具有幂等语义，多次执行同一个GET请求，客户端期望产生的服务器业务效果应当相同。
POST则不保证幂等。
例如：
POST /create-order
如果因为网络问题重复发送两次，理论上可能创建两张订单。
因此支付、订单和其他重要业务系统通常还需要结合订单号、唯一请求标识或服务器端防重复机制，而不能只依赖POST方法本身。
GET与SEO的关系更直接
文章、分类、搜索结果和筛选页面如果需要被分享、收藏或作为稳定页面访问，通常需要对应明确URL。
例如：
/article/123 /search?q=seo /category?page=2
GET很适合这种场景。
但参数过多也可能制造大量重复URL：
/product?id=123&sort=1 /product?id=123&sort=2 /product?id=123&utm_source=test
如果这些地址实际展示相同或高度相似内容，就需要考虑Canonical、内部链接和参数URL管理等问题。
POST更适合提交动作，而不适合作为需要长期分享和直接访问的页面入口。
实际开发怎么选
可以先从请求目的判断：
读取、搜索、查询 → GET 提交表单、创建数据、执行操作 → POST
例如：
查看文章：GET；
搜索关键词：GET；
商品分页：GET；
用户登录：POST；
发表评论：POST；
创建订单：POST；
上传文件：POST。
实际API设计中还有PUT、PATCH、DELETE、HEAD和OPTIONS等方法，GET与POST只是其中最常用的两种。
理解两者时，不要只记住“一个参数在URL，一个参数在Body”。更准确的判断方式是看这个请求到底想做什么：GET表达的是读取资源，POST表达的是提交数据进行处理。参数位置、安全性和缓存行为，都是建立在这种请求语义之上的具体差异。
精彩评论