免费 AI IDE
GET 和 POST 是 HTTP 里最常用的两种请求方法，区别的核心在两点：GET 把参数放在网址里、主要用来取数据；POST 把参数放在请求体里、主要用来提交数据。理解这一句，后面四个关键点就都好懂了。本文用办事窗口的比喻，讲清两者在参数位置、语义幂等、缓存历史、安全性与选型上的区别，并给出可对照的代码示例，帮你不再把两者混为一谈。掌握它，是写对任意前后端交互的第一步。
一、先建立直觉：GET 是去拿，POST 是去交
把 HTTP 请求想象成去办事。GET 像「去窗口问个信息」——你报上要查什么（写在网址里），对方把结果念给你听，窗口本身不留下任何改变。POST 像「去窗口填表交材料」——你把表格内容塞进信封（请求体）递进去，对方据此帮你办一件事，比如开户、下单。
这种语义区别不是规定死的技术限制，而是 HTTP 协议给这两种方法定下的「约定用法」。GET 语义上是「只读」，POST 语义上是「会改动点什么」。照着语义用，别人读你的接口才不费解；反过来乱用，后期维护会非常痛苦。为什么叫「方法」？因为 HTTP 协议定义了多种请求动作（GET、POST、PUT、DELETE 等），方法就是这次请求「想干什么」的声明。这套声明本质上是让「客户端想做什么」和「服务端怎么响应」形成共识，没有这层共识，Web 根本无法协作。想弄清请求响应这套模型，可以先看 HTTP 教程 把基础打牢。
二、关键点一：参数放哪（网址 vs 请求体）
这是最直观的区别。GET 的参数跟在网址后面，用 ? 隔开、用 & 连接，例如 https://example.com/search?keyword=手机&page=1，「keyword=手机」和「page=1」都明晃晃写在地址栏。POST 的参数则放在请求体里，网址干干净净，参数藏在报文内部，不在地址栏显示。
用 curl 能直观看到两者的差别：
# GET：参数明文跟在网址后面
curl "https://example.com/search?keyword=手机&page=1"
# POST：参数藏在请求体里
curl -X POST -d "keyword=手机&page=1" https://example.com/search这带来两个连带影响：GET 的参数是「可见的」，不适合传密码；POST 的参数「不可见」，更适合传敏感或体积大的内容（比如上传一张照片的描述）。还要注意一个现实限制：网址长度不是无限的，不同浏览器和服务器对 URL 长度都有上限（通常几千字符），所以 GET 不适合塞超大参数，超了就得改用 POST。这也是为什么 GET 请求不适合传大段 JSON——它该待在 POST 的请求体里。GET 的参数还会被浏览器自动做 URL 编码，中文和特殊符号会被转义成 %xx 形式，你看到的网址可能是一串编码后的字符，这是正常的安全处理，不是乱码。这也是为什么搜索结果能以链接形式分享——参数本就写在网址中，天然可传播、可收藏，对方打开同一网址就能看到同样内容，无需任何额外状态。
三、关键点二：语义、幂等与缓存历史
第二关键点关乎「该用哪种才规范」。GET 被定义为幂等且安全：幂等意思是「同样的请求发一百次，结果都一样、不产生副作用」；安全意思是「它不该修改服务器上的数据」。所以刷新一个 GET 请求通常无害。POST 不保证幂等——提交订单发两次，可能就下了两单，这正是很多支付页面会提醒「不要重复点击」的原因。
连带地，GET 的响应可以被浏览器缓存、可以被收藏进书签、会留在历史记录里；POST 一般不被缓存、也不方便收藏。这也是为什么「搜索」「翻页」多用 GET（结果可分享、可回退），而「登录」「下单」多用 POST（动作不可随意重放）。一个具体例子：你把 ?keyword=手机 的搜索结果页加入书签，下次直接打开还是同一批结果；但一个「提交订单」的 POST 页面你绝不会想收藏，因为重放它可能又下一单。书签这个特性对产品很实用：把 GET 结果页分享出去，对方无需登录态也能看到同样内容；POST 做不到这点。理解系统怎么拆成服务，再补 软件工程教程 会更有体感。
四、关键点三与四：安全性误区与到底怎么选
第三个关键点要先破除误区：POST 不比 GET 更安全。很多人以为「参数不在网址里」就等于安全，其实抓包工具一眼就能看到请求体。真正的防护来自 HTTPS 加密传输和服务器校验，而不是选了 POST 就高枕无忧。HTTPS 的作用是把整段通信（无论 GET 还是 POST）都加密，让中间人看不到内容；没有它，两者都裸奔。第四个关键点是怎么选：问自己两个问题——「这次操作会不会改动数据？」会改动就用 POST；「参数能不能出现在网址、结果能不能被缓存分享？」能且只是查数据，就用 GET。
一个最常见的真实例子是登录表单：用户名密码通过 POST 提交，浏览器不会把它们留在地址栏，刷新页面也不会重复提交；而搜索框用 GET，你甚至能把带参数的搜索网址发给同事，他打开就是同一结果。把这两个场景记住，GET 和 POST 的区别就彻底落地了。选型时如果拿不准，记住一条底线：任何会写数据库、扣余额、发消息的动作，一律 POST；纯读取展示的，才考虑 GET。遇到术语卡壳，编程词典 里有通俗解释。
再补充一个新手常问的点：GET 和 POST 之外还有 PUT、DELETE、PATCH 等方法，它们同样属于 HTTP 动词，用于表达「更新」「删除」「局部改」等更细的动作。但在真实简单的前后端交互里，九成场景用 GET 和 POST 这对组合就足够，不必一上来就纠结其余方法。等把这一对用熟，再去了解 RESTful 风格如何用不同动词映射不同操作，会顺理成章得多。选型时若仍摇摆，回到那句底线：会写数据、扣余额、发消息的动作一律 POST，纯读取展示的才考虑 GET。
总结
GET 和 POST 怎么区分，记住这四句：参数位置（网址 vs 请求体）、语义（只读取 vs 会改动）、缓存历史（可分享 vs 不可）、安全（都不天然安全，靠 HTTPS）。最省心的用法是「取用 GET、交用 POST」，把语义摆在第一位，再考虑便利与长度限制。
延伸学习
常见问题
Q1：GET 和 POST 能互相替代吗？
技术上都能传数据，但语义错用会带来缓存、幂等、书签等一连串麻烦。按「取用 GET、交用 POST」的约定走，是最省心的做法。
Q2：POST 的参数真的不在网址里，就更安全吗？
不是。POST 只是不显示在地址栏，抓包依然可见。保密靠的是 HTTPS 加密和后端校验，与 GET/POST 选择无关。
Q3：为什么有的接口用 POST 来「查数据」？
常见原因是参数太长（超出网址长度限制）或含敏感字段。这时即便语义上是查询，也会用 POST 把参数塞进请求体，属于务实的例外。
