必须用而不能用包裹，因为提供浏览器原生的语义化、键盘导航（Tab/回车）、屏幕阅读器识别、防重复提交等安全交互能力，完全缺失这些保障。
安全设置页面不是普通表单，必须默认启用语义化、可访问性、防篡改三重保障；用 <form></form> 是底线，不是选项。
为什么必须用 <form></form> 而不能用 <div> 包裹？
<p>安全操作（如修改密码、绑定邮箱、开启两步验证）依赖浏览器原生能力：回车提交、<code>Tab 键顺序聚焦、屏幕阅读器识别控件关系、自动禁用提交按钮防重复点击。纯 <div> 会直接丢失这些能力。
<ul>
<li>
<code><form></form> 即使不设 action 和 method，也能保有语义和键盘交互逻辑
onsubmit="return false" —— 它会切断浏览器默认防重复机制；应改用 event.preventDefault() + 手动控制<label for="xxx"></label> 或包裹式 <label><input></label>，否则屏幕阅读器无法关联“新密码”和对应输入框
input[type="password"] 怎么防止粘贴明文或绕过强度校验？
类型只是提示，用户仍可粘贴任意字符串、用开发者工具删掉 pattern 属性。真正起作用的是 JS 实时监听 + 后端双重校验。
- 监听
input事件，而非只靠blur—— 用户可能不离开输入框就点保存 - 对密码字段加
autocomplete="new-password"，减少浏览器自动填充干扰 - 不要用
pattern做唯一校验：它只在提交时触发，且正则易被绕过；JS 中需同步检查长度、大小写字母、数字、特殊字符 - 密码确认字段必须 JS 实时比对，不能只靠
required—— 用户可能填两个不同但都合法的密码
敏感操作（如解绑手机号、关闭两步验证）为什么要单独分组并加二次确认？
这类操作不可逆，且常被钓鱼脚本批量触发。HTML 层面必须用 <fieldset disabled></fieldset> 隔离，并强制显式激活。
立即学习“前端免费学习笔记（深入）”；
- 用
<fieldset></fieldset>+<legend></legend>包裹高危项，而不是<div class="danger-section"> —— 前者能被辅助技术识别为逻辑组，后者只是视觉装饰 <li>初始状态设 <code>disabled，仅当用户主动勾选“我理解风险”复选框后，才用 JS 移除disabled属性 - 保存按钮必须是
<button type="submit"></button>，且提交前 JS 检查该<fieldset></fieldset>是否已解除禁用；否则直接拦截 - 禁用状态下的
<input>仍会随表单提交 —— 若未加disabled到<fieldset></fieldset>，而只加在单个控件上，就可能漏掉数据
最容易被忽略的是：所有安全操作的响应必须带明确状态码（如 HTTP 403 表示权限不足），前端不能仅靠 UI 禁用就认为“已防护”。浏览器禁用只是障眼法，真实校验永远在服务端。
