disabled属性是唯一真正禁用表单控件的方式，使元素不可聚焦、不响应交互且值绝不出现在提交数据中；仅对input、textarea、select、option、optgroup、button、fieldset等原生表单控件生效，div、span、label等无效，JS须用el.disabled=true/false操作，服务端必须校验。
disabled 属性是唯一能真正禁用表单元素的方式，它让控件不可聚焦、不响应交互、且值绝不会出现在提交数据中。别指望 pointer-events: none 或 CSS 灰色样式来替代——它们既不阻止提交，也不被屏幕阅读器识别为“禁用”。
哪些元素加 disabled 才真正生效
只对原生可交互表单控件有效：input（含 type="text"、"checkbox"、"radio" 等）、textarea、select、option、optgroup、button、fieldset。
以下写法完全无效，浏览器直接忽略：
- 内容
段落
-
（label本身不支持disabled，里面input依然可操作） -
（只要属性名存在，就禁用；值是什么无关紧要）
JS 动态控制 disabled 的正确姿势
必须操作 DOM 属性 .disabled，而不是用 setAttribute 或 removeAttribute：
- ✅ 启用：
el.disabled = false - ✅ 禁用：
el.disabled = true - ❌ 避免：
el.setAttribute('disabled', '')（语义不严谨，旧 Safari 可能不触发底层状态更新） - ❌ 避免：
el.removeAttribute('disabled')（IE ≤ 11 和 Safari ≤ 15.6 中常不重绘 UI）
检查状态也应写 if (el.disabled)，而不是 el.hasAttribute('disabled')——后者可能滞后，尤其在 fieldset 继承禁用时返回 false，但实际已禁用。
fieldset 批量禁用为什么有时失效
fieldset[disabled] 是最简洁的批量方案，但它有明确的失效边界：
- 子控件显式写了
disabled（哪怕写成disabled=""或disabled="false"），多数现代浏览器仍以子元素声明为准，父级禁用被覆盖 - 控件不在
fieldset的 DOM 子树内，例如指向的是外部，点击label就绕过禁用 - 用了 Vue/React 封装组件或 Shadow DOM——原生继承链断裂，禁用无法穿透
-
fieldset设置了display: flex或grid——Safari 和 IE11 下部分子控件可能视觉灰显但焦点仍可进入
验证是否生效最快方式：el.matches(':disabled') 返回 true 表示确实禁用；若 el.hasAttribute('disabled') 是 false，说明禁用来自父级 fieldset。
禁用后容易被忽略的副作用
禁用不是静默结束，而是一连串隐性影响：
- 焦点不会自动移走，用户按 Tab 可能卡在已禁用元素上；应手动调
nextFocusable.focus() - 禁用的
input、select、textarea值不会出现在FormData或form.submit()中——服务端必须校验，前端禁用可被绕过 - 若用
readonly替代，它对select、checkbox无效，且值照常提交，极易导致后端收不到字段或收到意外值 -
legend文本不受fieldset[disabled]影响，仍可聚焦、可读取；如需一并屏蔽，得额外加 CSS 或 JS 控制
最常被漏掉的点：禁用后没同步更新表单验证逻辑（比如保留 required 属性），或没处理框架响应式状态（Vue/React 中仅改 DOM 的 .disabled，下次 re-render 会覆盖）。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
