必须用而不能用包裹，因为提供浏览器原生的语义化、键盘导航（Tab/回车）、屏幕阅读器识别、防重复提交等安全交互能力，完全缺失这些保障。

安全设置页面不是普通表单，必须默认启用语义化、可访问性、防篡改三重保障；用

是底线，不是选项。

为什么必须用

而不能用

包裹？

安全操作（如修改密码、绑定邮箱、开启两步验证）依赖浏览器原生能力：回车提交、Tab 键顺序聚焦、屏幕阅读器识别控件关系、自动禁用提交按钮防重复点击。纯

会直接丢失这些能力。

• 即使不设 action 和 method，也能保有语义和键盘交互逻辑
• 禁用 onsubmit="return false" —— 它会切断浏览器默认防重复机制；应改用 event.preventDefault() + 手动控制
• 每个输入项必须配 或包裹式 ，否则屏幕阅读器无法关联“新密码”和对应输入框

input[type="password"] 怎么防止粘贴明文或绕过强度校验？

类型只是提示，用户仍可粘贴任意字符串、用开发者工具删掉 pattern 属性。真正起作用的是 JS 实时监听 + 后端双重校验。

• 监听 input 事件，而非只靠 blur —— 用户可能不离开输入框就点保存
• 对密码字段加 autocomplete="new-password"，减少浏览器自动填充干扰
• 不要用 pattern 做唯一校验：它只在提交时触发，且正则易被绕过；JS 中需同步检查长度、大小写字母、数字、特殊字符
• 密码确认字段必须 JS 实时比对，不能只靠 required —— 用户可能填两个不同但都合法的密码

敏感操作（如解绑手机号、关闭两步验证）为什么要单独分组并加二次确认？

这类操作不可逆，且常被钓鱼脚本批量触发。HTML 层面必须用

隔离，并强制显式激活。

DeepBI DHTML 页面生成器

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

下载

• 用
  +
  包裹高危项，而不是
  —— 前者能被辅助技术识别为逻辑组，后者只是视觉装饰
• 初始状态设 disabled，仅当用户主动勾选“我理解风险”复选框后，才用 JS 移除 disabled 属性
• 保存按钮必须是 ，且提交前 JS 检查该
  是否已解除禁用；否则直接拦截
• 禁用状态下的 仍会随表单提交 —— 若未加 disabled 到
  ，而只加在单个控件上，就可能漏掉数据

最容易被忽略的是：所有安全操作的响应必须带明确状态码（如 HTTP 403 表示权限不足），前端不能仅靠 UI 禁用就认为“已防护”。浏览器禁用只是障眼法，真实校验永远在服务端。