不是安全机制，只是传输通道；它可被轻易篡改，所有值对攻击者等同明文，必须依赖服务端对每个字段做存在性、所有权和合法性三重校验。
不能用 <input type="hidden"> 传递安全参数——它根本不是安全机制，只是传输通道。
为什么 hidden 字段不等于安全字段
浏览器里右键“检查元素”，两秒就能改 value；用 curl 或 Postman 手动构造请求，连页面都不用打开。所有藏在 <input type="hidden"> 里的值，对攻击者来说和明文无异。
- 它不加密、不签名、不校验来源，只是普通表单字段
- 服务端收到的
status="paid"可能是用户自己填的，不是系统生成的 - 哪怕加了
disabled或readonly，也挡不住 DOM 修改或绕过提交
哪些参数看似“安全”实则危险
以下字段一旦仅靠 hidden 传递且后端不做强校验，极易引发越权、资损或逻辑绕过：
-
price、discount_amount：金额必须由服务端查库/重算，前端只传product_id -
role、permission_level：权限判定必须基于 session 或 token 中的服务端签发信息 -
order_status、is_verified：状态变更需走完整业务流程，不能靠前端传一个字符串就更新数据库 -
user_id（非当前登录态关联）：若用于“代操作”，必须二次鉴权（如校验操作者与目标用户的绑定关系）
真正该做的：用 hidden 传上下文，用服务端控逻辑
hidden 字段唯一合理的角色，是携带服务端已确认、可复验的上下文标识，例如：
-
csrf_token：必须和服务端 session 中存储的 token 严格比对，且一次有效 -
order_id：必须存在且属于当前用户，查询时带WHERE user_id = ? AND id = ? -
redirect_url：必须白名单校验（如startsWith("https://myapp.com/")），不能直接跳转 -
ab_test_group：仅作埋点用，不参与核心逻辑分支
所有这些字段，后端必须做「存在性 + 所有权 + 合法性」三重检查，缺一不可。
容易被忽略的关键点
很多团队在上线前漏掉这两件事：
- 没关掉浏览器自动填充：Chrome 会把
type="hidden"当成普通字段填入历史值，导致value被覆盖（尤其在多账号切换场景） - JS 动态赋值后没防重放：比如
timestamp字段只设了一次，但表单可重复提交，后端没校验时间窗口
真正的安全不在前端藏得多深，而在服务端判得多严——hidden 字段只是信封，信的内容真伪，得由收信人当场验签。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
