fieldset disabled仅禁用原生表单控件（input/select/textarea/button/output），不作用于legend内控件、contenteditable元素、自定义组件及显式设disabled的子元素；旧版Safari和IE不支持，需JS兜底；禁用后值不参与提交，且嵌套fieldset无法取消继承禁用。
fieldset 的 disabled 属性确实能批量禁用分组，但它的生效范围、行为边界和兼容性陷阱比表面看起来复杂得多——不是加个属性就万事大吉。
fieldset disabled 禁用哪些元素？
它只对原生可交互表单控件起作用，且有明确白名单：input、select、textarea、button、output。其他元素完全不受影响：
-
legend内的任何控件（比如<legend> <input type="checkbox">同意条款</legend>）始终可操作，这是 HTML 规范强制行为，不是 bug -
contenteditable="true"的div或span不会被禁用，键盘仍可编辑 - 自定义组件（如 Vue 的
<my-input></my-input>、React 封装的Input）若未将disabled透传到底层input，就会“逃逸”禁用逻辑 - 显式设置了
disabled=""或disabled="false"的子控件：前者等价于disabled=true，后者在 HTML 中仍被解析为 true（浏览器忽略值内容），优先级高于外层 fieldset
为什么有些 input 还能点、能提交？
常见现象不是属性没生效，而是被其他逻辑覆盖或绕过：
- 子
input自己写了disabled="false"—— 浏览器以子元素显式声明为准，父级无法强制覆盖 - 用了
label包裹控件，但for指向错误 ID，导致点击 label 实际触发了外部未禁用控件 - JavaScript 直接调用
el.focus()或监听click事件，而没检查fieldset.disabled状态；禁用只拦截原生交互，不阻止 JS 执行 - 表单提交时发现字段值缺失：因为
fieldset禁用后，内部控件的值默认不参与序列化（FormData、form.elements遍历时仍存在，但el.disabled === true）
动态控制时该用 .disabled = true 还是 removeAttribute("disabled")？
必须统一用赋值方式，避免兼容性断裂：
立即学习“前端免费学习笔记（深入）”；
-
el.disabled = true和el.disabled = false在所有现代浏览器中行为一致，包括 Safari ≤ 15.6 的 fallback 场景 -
el.removeAttribute("disabled")在旧 Safari 和 IE 中可能不重绘状态，控件看起来仍灰显但实际可交互 -
el.disabled = null或undefined不会清除禁用状态，只认布尔值 - 服务端渲染时，用
disabled="disabled"比disabled=""更稳妥，XHTML 兼容性更好
兼容性兜底和无障碍关键点
Firefox 动态插入的 fieldset 可能读不到 .disabled 初始值（返回 undefined），Safari ≤ 15.6 和 IE 完全不支持该属性——这些都不能靠“尽量不用”来规避：
- 判断是否禁用，优先用
el.hasAttribute("disabled")，而非el.disabled === true - 需要兼容旧浏览器时，必须 JS 遍历子元素设
disabled，并监听fieldset属性变化（MutationObserver）同步状态 - 不要给
fieldset加style="pointer-events: none"模拟禁用：它不影响表单提交、不阻止键盘操作、不改变焦点流，纯属视觉欺骗 -
aria-disabled="true"和原生disabled不要共存，屏幕阅读器可能重复播报
真正麻烦的是嵌套：外层 fieldset disabled 包着一个启用的内层 fieldset，内层控件依然不可用——disabled 是继承的，无法被子元素取消。如果业务需要局部启用，只能放弃 fieldset disabled，改用 class 控制 + JS 手动管理每个控件状态。
