hidden字段必须严格满足type="hidden"、name匹配后端键名、value显式写出才生效；它非安全机制，仅作数据传输，防篡改须依赖后端动态token校验与业务逻辑兜底。
hidden 字段写错 type 就变成可见文本框
浏览器只认 type="hidden" 这个精确字符串，大小写、拼写差一点就失效。写成 type="Hide"、type="hide" 或直接省略 type，浏览器会按默认 type="text" 处理——字段立刻显示在页面上，用户可编辑、清空、甚至被 CSS 意外暴露。
必须同时满足三个条件才算真正生效：
-
type属性值严格等于"hidden"（小写、无空格） -
name属性存在且拼写与后端接收键名完全一致（区分大小写） -
value属性显式写出，哪怕为空：value=""；不写value属性则该字段压根不提交
hidden 字段不是安全机制，只是数据运输载体
它不校验、不加密、不防篡改——DevTools 里双击就能改 value，curl 直接 POST 就能绕过页面。所谓“防重”“防 CSRF”，全靠后端配合：submit_token 或 csrf_token 的 value 必须由服务端动态生成、绑定当前 session、带签名或时效（如 JWT）、一次性消费（校验后立刻从 session 删除）。
常见失效场景：
立即学习“前端免费学习笔记（深入）”；
- 前端用
Math.random()生成 token → 攻击者可预测或重放 - HTML 页面被 CDN 缓存 → 用户拿到过期 token
- 后端校验逻辑放在业务处理之后 → 重复请求已执行两次
- token 未绑定用户 session ID → 可被跨账号复用
哪些值能放 hidden，哪些绝对不能
能放的：服务端已确认、客户端无需干预、仅需原样回传的上下文信息。比如：return_url、step=2、order_id=12345。
不能放的：任何可能被篡改导致资损或越权的值。例如：
-
price="99.00"→ 用户改成price="0.01"，后端若直接读取就亏钱 -
role="admin"→ 改成 admin 就提权 -
is_paid="false"→ 改成 true 就跳过支付流程
这类逻辑必须由后端从 session / JWT / 数据库中重新查，而不是信任 hidden 字段。
JS 动态改 hidden 值时最易忽略的两个点
很多项目用 JS 更新 input[name="active_tab"] 或 timestamp，但容易漏掉关键约束：
- 初始
value必须在 HTML 中写死（哪怕是个占位符），不能全靠 JS 初始化——JS 加载失败或延迟时，后端收到空值或旧值 - 多个互斥 hidden 字段（如
action="create"和action="update"）修改后，必须在form.onsubmit开头做一致性校验，不能只等后端兜底 - 框架项目（Vue/React）别直接操作 DOM 的
value，要用响应式绑定（v-model或value={this.state.x}+onChange）
真正难的不是怎么写这个标签，而是每次加之前都得问一句：如果这个值被恶意改成任意字符串，后端是否依然安全？答案不是“是”，就别放进去。
