hidden字段本身不防重，仅作为token运输载体；关键在后端动态生成、绑定session、一次性消费及前端禁用按钮配合。
Hidden字段本身不防重，只是token的运输载体
input type="hidden" 在防重机制里纯粹是个“快递员”：它不校验、不拦截、不判断，只负责把后端生成的 submit_token 安全带到服务端。很多开发者误以为只要加了这个字段，表单就自动防重了——这是最常踩的坑。关键逻辑完全不在 HTML 层，而在于：submit_token 是否由后端动态生成、是否绑定 session、是否一次性消费、前端是否配合禁用按钮防止高频点击。
Hidden字段的value必须每次页面加载都刷新
如果 value 是硬编码（比如 value="abc123"）或前端用 Math.random() 生成，整个防重链路就失效了。正确做法是：
- 服务端在渲染表单页时，生成一个带签名、有时效的 token（如 JWT 或 HMAC-SHA256 签名的字符串）
- 该 token 必须写入当前用户的 session，并同时塞进
<input type="hidden" name="submit_token" value="..."> - 用户刷新页面时，服务端必须重新生成新 token 并更新 session，旧 token 失效
- 不能缓存含该字段的 HTML 页面，否则浏览器可能复用过期 token
Hidden字段名和校验逻辑必须前后端严格一致
常见错误是前端写 name="token"，后端却按 request.getParameter("submit_token") 去取——直接取不到，导致校验永远失败。务必确认：
- HTML 中
name属性与后端接收参数名完全一致（区分大小写） - 后端校验代码必须在业务逻辑执行前完成：先比对
submit_token和 session 中值是否匹配且未被消费 - 校验通过后，**立刻从 session 中移除该 token**，而不是等响应结束再清理
- 若校验失败，返回明确 HTTP 状态码（如
400 Bad Request）和提示，前端据此引导用户刷新页面
Hidden字段无法防御绕过表单的重复请求
攻击者用 curl、Postman 或脚本直接 POST 数据，完全可以跳过 HTML 页面，伪造任意 submit_token 值。所以：
立即学习“前端免费学习笔记（深入）”；
- token 必须带服务端可验证的签名，不能是纯随机字符串
- 必须设置合理有效期（建议 5–15 分钟），超时即拒绝
- 必须绑定用户 session ID 和表单类型（如
"order_form"），防止跨表单复用 - 即使有 hidden 字段，后端仍需配合幂等设计（如数据库唯一索引、状态机校验）作为兜底
