POST比GET请求方式更安全

把登录密码放在URL里，请求全等于把它写在明信片上寄出去。更安GET请求就是请求全这么干的。浏览器地址栏、更安服务器访问日志、请求全代理缓存、更安甚至你同事扭头看一眼屏幕，请求全都能看到完整参数。更安POST不会。请求全参数塞在请求体里，更安地址栏干干净净，请求全日志里只记路径不记内容。更安这不是请求全什么高深技巧，是更安HTTP协议最基础的区分。

我见过一个真实案例。请求全某小型电商后台的用户列表页用GET传分页和搜索条件，本来无所谓。但有个开发图省事，把筛选条件里的用户手机号直接拼进了URL。结果运维排查问题时翻Nginx日志，满屏都是手机号明文。后来他们改成POST，日志里就只剩/admin/users，干干净净。你说这算安全提升吗？算，而且是最低成本的那种。

浏览器对GET和POST的处理方式完全不同。GET请求可以被收藏、被历史记录、被分享链接。你想想，如果网银转账用GET，转完账地址栏留一串?to=xxx&amount=5000，你截图发给朋友看余额，顺手把转账记录也发出去了。POST没这个问题，刷新页面浏览器还会弹窗问你“是否重新提交表单”，这层确认本身就是一种保护。

缓存是另一个坑。GET响应默认可以被各级缓存存储——浏览器缓存、CDN缓存、反向代理缓存。如果接口返回的是用户隐私数据，缓存服务器可不管你是谁，下一个请求相同URL的人直接拿到缓存副本。POST响应默认不缓存，因为协议设计上就认为它可能改变状态，不该被随意复用。这个默认值救过不少人。

CSRF攻击也跟这有关。GET请求可以轻易被第三方页面触发——一张<img src="https://bank.com/transfer?to=hacker&amount=10000">就完事了。浏览器带着cookie就去了。POST虽然也不能完全免疫CSRF，但至少攻击者没法用img标签直接发POST，得构造表单或者用fetch，门槛高了一截。当然真正防CSRF要靠token，但POST这个门槛本身就有价值。

有人会说：抓包不都能看到吗？HTTPS不都能加密吗？对，但安全是分层的。HTTPS加密的是传输通道，POST保护的是数据在到达加密层之前的暴露面。你的浏览器历史记录、服务器日志、代理中间件——这些地方HTTPS管不着。POST把敏感数据从URL里挪走，等于减少了一层暴露。这不是替代HTTPS，是叠加。

还有一个容易被忽略的点：URL长度限制。GET参数挂在URL上，不同浏览器和服务器对URL长度限制从2KB到8KB不等。超过就截断，或者直接400。POST请求体理论上没上限（实际受服务器配置限制），传文件、传大段JSON都没问题。一个传不完整数据的请求，本身就不安全——你以为是A，服务器收到的是B。

当然POST不是万能药。它不加密、不鉴权、不防重放。把POST当安全银弹是另一回事。但在“别把密码写在地址栏”这个层面上，它比GET靠谱得多。下次设计接口，凡是涉及用户输入、身份凭证、隐私数据的，默认用POST。这个习惯不费劲，但能省掉很多事后擦屁股的麻烦。