你填完登录框，网页点下那个“登录”按钮。网页浏览器弹出一个提示：“确认重新提交表单？网页”——这场景太常见了，常见到大多数人直接点“继续”，网页然后页面刷新，网页一切正常。网页但如果你正好在买一张限量球票，网页或者提交一份已经填了半小时的网页报销单，这一下可能会让你骂出声来。网页

这就是网页网页 POST 最直观的“副作用”。它不像 GET 那样把参数挂在 URL 后面，网页你一眼就能看见。网页POST 把数据塞进 HTTP 请求的网页 body 里，地址栏干干净净。网页好处是网页能传大量数据、传文件、传密码——坏处是，刷新页面时浏览器不知道你刚才到底干了什么，于是它谨慎地问一句：要不要再发一次？

一个请求，两种姿势

GET 和 POST 的区别，很多人背过八股文：GET 是获取数据，POST 是提交数据。这话没错，但不够用。真正有意思的是它们在网络层的表现。

你打开一个商品详情页，浏览器发的是 GET。URL 里带着商品 ID，比如 /item?id=12345。服务器返回 HTML，浏览器渲染出来。整个过程是“读”。你点“加入购物车”，浏览器发的是 POST。请求体里可能藏着 item_id=12345&quantity=1&csrf_token=...。服务器收到后，改数据库，返回一个重定向或者成功状态。整个过程是“写”。

读操作可以缓存、可以收藏、可以分享链接。写操作不行。你没法把“转账 500 块”这个动作做成一个 URL 发给朋友，说“你点一下”。这就是设计上的根本区分：GET 应该是幂等的——发一次和发十次，服务器状态不变。POST 不保证这个。

CSRF 和那个隐藏字段

POST 有个经典安全问题：跨站请求伪造。假设你登录了银行网站，cookie 还在。然后你手滑点开一个恶意页面，里面藏着一个自动提交的表单，action 指向银行转账接口，收款人写的是攻击者。浏览器一看，目标域名是银行，cookie 自动带上，POST 请求就发出去了。银行服务器无法区分这是你本人操作还是恶意页面伪造的。

解决办法之一是在表单里塞一个随机 token，服务器端也存一份。每次 POST 必须带上这个 token，恶意页面拿不到，请求就废了。你打开任何正经网站的源代码，搜 csrf 或者 _token，大概率能找到那个隐藏的 input。这东西不显眼，但没它，很多网站就是裸奔。

表单编码那点事

POST 请求体不是随便写的。浏览器提交表单时，默认用 application/x-www-form-urlencoded 编码，长得像 name=value&name2=value2，特殊字符会被百分号转义。如果表单里有文件上传，编码会变成 multipart/form-data，每个字段用 boundary 隔开，二进制文件直接塞进去。这两种格式服务器端解析方式不同，写后端时如果搞混，就会收到空值或者乱码。

还有第三种：application/json。这不是 HTML 表单默认的，而是前端用 fetch 或 XMLHttpRequest 手动设置的。现在前后端分离的项目里，JSON 才是主流。你打开开发者工具，Network 面板里看 POST 请求，Payload 标签下经常是一坨 JSON。服务器拿到后解析，比表单编码灵活得多。

刷新之后发生了什么

回到开头那个提示。浏览器为什么问？因为 POST 请求通常对应一个“动作”，而不是一个“资源”。你提交订单，服务器创建了一条记录。如果刷新时再发一次，可能就创建了第二条。浏览器没法知道服务器端是不是幂等的，所以它选择问用户。

解决方案是 PRG 模式：POST 处理完后，服务器返回 302 重定向到一个 GET 页面。浏览器自动跳转，地址栏变成 GET URL。这时候再刷新，只是重新 GET 那个页面，不会重复提交。你平时购物下单后跳转到“订单成功”页，就是这个模式。

所以下次看到那个“确认重新提交表单”的弹窗，别急着点。想一下：你刚才那个操作，重复一次会怎样？如果答案是“会多扣一笔钱”或者“会多发一条评论”，那就老老实实关掉页面，重新走一遍流程。POST 不负责帮你记住状态，它只负责把数据送出去。

(责任编辑：综合)