hidden字段仅解决自动携带非敏感参数问题，不提供安全保护；敏感数据须由服务端校验、查库或签名验证，绝不可依赖其隐藏。

用 type="hidden" 在表单中传递关键业务参数，本质是让浏览器“悄悄带上值、不显示给用户”，但**它完全不提供安全保护**——值可被任意查看、修改。真正要保障参数安全，得靠服务端校验和权限控制，而不是依赖 hidden 字段“藏起来”。

hidden 字段的核心用途

它只解决“自动携带、无需用户输入”的问题，比如：

• 记录当前页面来源（如 ）
• 传递已生成的临时标识（如订单预提交时的 temp_order_id）
• 维持流程状态（如多步表单中的 step=2）

这些值本身不敏感，或即使被改也不影响核心业务逻辑——改了也无妨，或服务端会重新校验。

千万别用 hidden 传真正敏感或关键参数

例如：用户 ID、权限等级、商品价格、折扣比例、库存余量、支付金额……这些一旦写在 hidden 里，用户打开开发者工具就能看到并篡改，提交后服务端若直接信任，就会出大问题。

正确做法是：

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

• 用户 ID、角色等身份信息，从 session 或 token 中获取，不要依赖表单字段
• 价格、库存等业务数据，在服务端查数据库实时确认，不采信前端传来的任何数值
• 需要“防篡改”的参数，可用服务端签名（如 HMAC）+ hidden 字段组合，提交时验证签名是否匹配

使用 hidden 的实用建议

如果确实要用，注意以下细节：

• name 属性要有明确语义（如 next_action），避免用模糊名（如 data）
• value 尽量用服务端生成的不可预测值（如 UUID、加密令牌），而非简单数字或明文字符串
• 配合 CSRF token 使用（），防止跨站请求伪造
• 多个 hidden 字段可集中放在表单顶部或底部，保持 HTML 结构清晰

一个典型但安全的用法示例

用户在订单确认页点击“支付”，表单提交前，后端已生成唯一支付单号并存入 session。页面渲染时写入：

  
  
  立即支付

服务端收到后，只把 payment_no 当作查询键，去数据库查该单的真实状态、金额、归属用户——所有关键判断都在服务端完成，不信任任何 hidden 值。