请求方式get和post的区别

浏览器地址栏里敲个网址，请求回车，请求页面出来了。请求你填了个表单，请求点提交，请求数据到了服务器。请求这两件事背后，请求用的请求就是GET和POST——HTTP协议里最常用的两个请求方式。但很多人对它们的请求理解，停留在“GET是请求查，POST是请求改”这种粗浅层面。

先看GET。请求它的请求本质是“索取”。你把参数拼在URL后面，请求比如?请求page=2&size=20，服务器看到这个地址，就知道你想要第2页、每页20条。这玩意儿有个特性——它是可见的，会被浏览器历史记录、服务器日志、代理服务器层层留下痕迹。所以别在GET里塞密码，那是裸奔。

POST就不一样了。参数放在请求体里，URL干干净净，内容在开发者工具的Network面板里才看得到。但这不代表POST就更安全——它只是不在URL上暴露，抓包照样能看见明文。真正要防泄露，得上HTTPS。

有个细节很多人忽略：GET请求会被浏览器主动缓存。你刷新一个列表页，浏览器可能直接给你看缓存结果，压根没发请求。POST不会，它每次都得老老实实跑到服务器。这意味着，同样是查数据，如果你用POST，每次都得重新拉取，慢且费流量。

再说说长度限制。老教材总说“GET有长度限制，POST没有”，这话误导人。实际上，HTTP协议本身没规定长度，是浏览器和服务器自己定的。IE对URL长度敏感，超过2KB就报错。但现代浏览器能容忍几KB的URL，服务器端如Nginx默认可以处理8KB的请求行。POST的请求体理论上可以很大，但服务器同样有client_max_body_size这种配置。所以别把POST当无限容量的U盘。

还有一个行为差异——后退和刷新。你点浏览器的后退按钮，如果之前是GET请求，页面会直接从缓存恢复，瞬间完成。但如果是POST，浏览器会弹出一个烦人的对话框：“确认重新提交表单？”因为它担心你重复提交订单、重复转账。这个细节暴露了POST的另一个特性：非幂等。GET是幂等的，发100次和发1次结果一样，服务器状态不变。POST不同，每发一次都可能产生新数据——比如提交一条评论、下个订单。

我见过不少开发者在做搜索功能时用POST，理由是“怕URL太长”。但搜索本身就该是GET——用户可以复制链接分享给朋友，浏览器能记住历史记录，爬虫也能抓取。你用POST做搜索，等于放弃了这些天然优势。

反过来，有些操作你千万别用GET。比如删除文章、转账、修改密码。因为GET请求可能被预加载、被爬虫访问、被浏览器预取。你写了个delete?id=1的链接，搜索引擎的爬虫来抓取时，服务器就把文章删了。这种事故在真实项目里发生过不止一次。

说到底，GET和POST的选择不是技术问题，是语义问题。你是在查询资源，还是提交数据？你希望这个操作可被缓存、可被收藏，还是必须每次新鲜送达？想清楚这两个问题，选择自然就出来了。别死记硬背“查用GET、改用POST”的教条——有些查询操作因为参数复杂，用POST反而更合适，比如地图上画个多边形区域搜索POI，坐标点几百个，塞进URL里既不现实也不优雅。

浏览器地址栏、收藏夹、分享链接、爬虫、缓存、历史记录——这些日常行为都在无形中检验你对请求方式的理解。用错了，用户可能发现复制了链接给别人，打开却是“页面已失效”。用对了，一切都顺滑得让人感觉不到它的存在。