直接加 disabled 属性是唯一可靠方式，可使表单控件真正不可用（不能点、输、聚焦，值不提交）；仅对 input、textarea、select、button 等原生可交互元素生效，对 div、span、label 无效。
直接加 disabled 是唯一可靠方式
想让一个表单控件真正不可用——不能点、不能输、不能聚焦、值不提交——必须用原生 disabled 属性。CSS 的 pointer-events: none 或 opacity 只是视觉障眼法，Tab 键仍能聚焦，回车仍可能触发表单提交，后端照样收到字段值。
它只对原生可交互元素生效：input（含 type="text"、"checkbox"、"radio"、"submit" 等）、textarea、select、button、optgroup、option、fieldset。给 div、span、label 加 disabled 属性完全无效，浏览器直接忽略。
常见错误写法：
-
<input disabled="false">——disabled是布尔属性，存在即禁用，值是什么都不影响 -
<label disabled><input></label>——label不响应disabled，里面input依然可操作 -
<input readonly>代替disabled——readonly允许聚焦、允许复制、值照常提交，且对select、checkbox无效
disabled 在 JS 中必须用 .disabled = boolean 控制
动态禁用/启用时，别用 setAttribute('disabled', '') 或 removeAttribute('disabled')。前者在部分旧浏览器下语义不严谨，后者在某些场景下不触发重绘，UI 看似没变。
正确做法是直接操作 DOM 属性：
-
el.disabled = true—— 禁用，稳定、可读、跨浏览器一致 -
el.disabled = false—— 启用，注意：仅设为false才有效，不能只删属性 - 禁用后若该元素正获得焦点，焦点不会自动移走，用户按 Tab 可能卡住；应手动调
nextElement.focus() - 如果之前有
required，禁用后 HTML5 验证会跳过，但checkValidity()缓存状态可能残留；建议禁用后顺手调一次reportValidity()
用 fieldset 批量禁用时要注意继承覆盖规则
把一组控件包进 <fieldset disabled>，是最简洁的批量方案，浏览器会递归禁用所有子表单控件（包括嵌套的 fieldset）。
但以下情况会导致禁用失效或行为异常：
- 子控件显式写了
disabled="false"或disabled=""—— 多数现代浏览器仍以子元素显式声明为准，父级禁用被覆盖 -
label的for指向了fieldset外的控件 —— 点击 label 会绕过禁用逻辑 - 用了 Vue/React 封装的自定义组件，或 Shadow DOM —— 原生继承链断裂，
fieldset的禁用无法穿透 -
legend文本不受影响，仍可聚焦、可读取；如需一并“屏蔽”，得额外加 CSS 或 JS
服务端永远不能信任前端的 disabled
禁用只是前端体验控制，绕过极其简单：开发者工具里删掉 disabled 属性，或直接发 POST 请求带上字段值。权限判断、字段校验、业务逻辑约束，必须落在服务端。
尤其要注意的是：
-
disabled的控件值一定不会出现在FormData、form.submit()或序列化结果中 —— 这是 HTML 规范强制行为，不是 JS 控制的结果 - 如果业务上需要“显示但不可改 + 必须提交”，
disabled不适用，该用readonly配合隐藏域或服务端兜底 - 测试时务必用键盘 Tab 切换焦点，而不是只靠鼠标点击 —— 真正禁用的区域，Tab 应该完全跳过
