post和get的区别

打开浏览器开发者工具，切到Network面板，刷新一个页面。你会看到一堆请求飞来飞去，有的标着GET，有的标着POST。大多数人扫一眼就过去了，觉得这俩不过是“获取数据”和“提交数据”的代号。但真到了自己写接口、调bug、或者面试被追问的时候，才发现事情没那么简单。

我刚开始学Web那会儿，写了个表单，method忘了写，默认就是GET。结果用户提交完，刷新一下页面，浏览器弹窗问“是否重新提交表单”。换成POST之后，这个问题消失了。当时只觉得“哦，POST更高级”，后来才明白，这背后是HTTP协议对两种方法截然不同的设计意图。

GET的本质是“我要看这个东西”

GET请求把参数直接拼在URL后面，像这样：/search?q=键盘&page=2。这意味着什么？意味着这个URL本身就是完整的、可复制的、可分享的。你把链接发给朋友，他打开看到的内容和你一模一样。浏览器会缓存GET请求的结果，你按后退键，页面瞬间从缓存里蹦出来，不会重新问服务器要一遍。这是GET的天性——它假设同一个URL对应的资源是稳定的、幂等的。你请求一百次，服务器返回的东西应该一样，不应该因为你多刷了几次就多出一条订单。

但这里有个坑。URL长度是有限制的，虽然不同浏览器和服务器不一样，但大概几千个字符就到头了。你要是用GET传一个长文本、一张图片的base64，那肯定塞不下。更关键的是，参数全暴露在URL里，密码、token这些东西挂在地址栏上，历史记录、服务器日志、代理服务器全都能看到。我见过有人把登录接口写成GET，用户名密码直接拼在URL里，这跟把钥匙插在门上没区别。

POST不是“更安全的GET”

很多人以为POST就是把参数藏起来了，所以更安全。不对。POST的参数放在请求体里，地址栏看不到，但如果你用的是HTTP而不是HTTPS，抓包工具照样看得一清二楚。POST的安全性来自HTTPS，不是来自它自己。

POST真正的特点是：它不保证幂等。你发一次POST创建一个订单，再发一次，可能就创建了两个订单。浏览器不敢随便缓存POST的响应，也不敢在你按后退键的时候自动重发。所以那个“是否重新提交表单”的弹窗，其实是浏览器在保护你，怕你无意中重复提交。

还有一个细节：GET请求在浏览器里可以被收藏、可以存书签、可以放到<a>标签的href里。POST不行。你没法把一个POST请求存成书签，也没法在地址栏里直接敲一个POST请求出来。它天生就是“动作”，不是“地址”。

什么时候用哪个，其实没那么难判断

你要获取数据、搜索、翻页、加载图片——用GET。你要创建、修改、删除、提交表单、上传文件——用POST。这个规则简单到几乎不用想。但现实里总有人偷懒，比如用GET来删除数据：/delete?id=5。这很危险，因为浏览器预加载、爬虫、甚至某些安全软件会“好心”地提前访问这个链接，结果数据就没了。我亲身经历过一次，一个后台管理页面用GET做删除，结果某个浏览器插件扫描页面上的所有链接，把所有数据都删了。那之后我再也不用GET做任何有副作用的操作。

RESTful API流行之后，PUT、DELETE、PATCH也常用了。但GET和POST依然是最基础的两种。理解它们的区别，不是为了背面试题，而是为了在写代码的时候，脑子里能清楚地知道：这个请求会不会改变服务器状态？它能不能被缓存？用户刷新页面会怎样？把这些想明白了，选哪个方法根本不需要犹豫。

下次你打开开发者工具，看到那一排请求，不妨点开几个看看。GET的请求体是空的，POST的URL干干净净。一个像在图书馆里查目录，一个像往意见箱里投信。动作不同，规矩也不同。

很赞哦!（5265）