打开浏览器，在地址栏敲下一串字符，按下回车——你几乎从不关心这背后发生了什么。但每次你登录一个网站、提交一份表单，或者只是点开一个链接，HTTP协议就在暗处替你做了选择：用GET，还是用POST。

很多人第一次接触这两个词，是在HTML表单的method属性里。老师会说，GET把数据放在URL里，POST放在请求体里。这话没错，但只说了皮毛。真正有意思的是，这个看似简单的技术分叉，背后藏着一整套关于“如何对待数据”的哲学。

先看GET。它的全部意图都写在URL上。https://example.com/search?q=咖啡&page=2，任何人拿到这个链接，都能完整复现你刚才的搜索行为。这是GET的核心特征：幂等、可缓存、可书签、可分享。你刷新十次页面，结果不会变。你把这个链接发给朋友，他看到的内容和你一模一样。搜索引擎爬虫也偏爱GET，因为URL就是内容的身份证。

但GET有个硬伤：URL长度有限制。虽然HTTP协议本身没规定上限，但浏览器和服务器各有各的脾气。IE historically限制在2083个字符，Apache默认8190字节。更麻烦的是，URL里只能放ASCII字符，中文、空格、特殊符号统统要转义。你试试用GET传一张图片？那串Base64编码能把URL撑爆。

POST就不一样了。它把数据塞进请求体，URL保持干净。POST /login HTTP/1.1，后面跟一大段表单数据，长度理论上无上限。上传文件、提交长文本、发送JSON，全靠它。更重要的是，POST不是幂等的。你点两次“提交订单”，服务器可能创建两笔订单。浏览器会弹出“确认重新提交表单吗？”——这个烦人的提示，恰恰是POST在保护你。

有个细节容易被忽略：GET请求也可以带body，POST请求也可以带query string。协议没禁止，只是约定俗成不这么干。我见过一个API，用POST传查询参数，理由是“不想让参数出现在日志里”。这招有用，但有点旁门左道。

安全层面，GET和POST都不加密。HTTPS才是那道锁。但GET的参数会留在浏览器历史、服务器访问日志、代理服务器缓存里。密码放GET里？等于把钥匙插在门上还贴了张纸条。POST的参数虽然在body里，但如果不走HTTPS，中间人照样能截获。

RESTful API流行之后，GET和POST的分工更明确了。GET用来读，POST用来写。PUT、DELETE、PATCH各司其职。但现实很骨感：很多老系统只认GET和POST，于是POST被逼着干所有脏活累活——更新、删除、甚至查询。你看到POST /getUserList这种接口，别笑，那是历史遗留的妥协。

浏览器对两者的差别待遇也很有意思。GET请求可以被缓存、被预取、被并行发送。POST请求默认不缓存，浏览器会串行处理，避免顺序错乱。你打开一个页面，里面十个GET请求可能同时飞出去；换成十个POST，它们得排队。

我自己的习惯是：只要操作是“读取”且不改变服务器状态，优先GET。需要传敏感数据、长数据、或者会改变状态的操作，一律POST。别为了URL好看硬塞参数，也别为了“安全”把查询也改成POST——那只会让缓存失效、书签失效、分享失效。

最后说个真实案例。某电商网站把“加入购物车”做成了GET请求：/cart/add?id=123。结果有个用户把链接贴到论坛里，爬虫顺着爬了一遍，给几万个访客每人加了一件商品。这就是GET幂等性被滥用的代价。换成POST，爬虫就老实了。

GET和POST不是谁好谁坏的问题。它们是两把不同的钥匙，开不同的锁。选错了，轻则缓存失效，重则数据错乱。下次写表单的时候，多花三秒钟想想：这个操作，该用哪把钥匙？