fieldset disabled仅禁用input、select、textarea、button、output及嵌套fieldset，不作用于legend内元素、contenteditable元素、自定义组件及非表单元素；禁用后值不提交，且存在兼容性与无障碍陷阱。

fieldset disabled 属性到底禁用哪些元素

它只对原生可提交表单控件生效，且有明确白名单：input、select、textarea、button、output，以及嵌套的 fieldset（会继续向下递归）。其他一律无视：

• legend 内部任何内容（包括 input）完全不受影响——这是 HTML 规范强制行为，不是 bug
• contenteditable="true" 的 div 或 span 不会被禁用，键盘仍可编辑
• 自定义组件（如 <myinput></myinput>）若未将 disabled 透传到底层 input，就“逃逸”禁用逻辑
• label、div、span 等非表单元素加 disabled 属性无效，浏览器直接忽略

为什么有些 input 还能点、能输入、能提交

不是属性没写上，而是被更高优先级逻辑覆盖或结构异常绕过：

PigX UI 前端开发

PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。

下载

• 子 input 显式写了 disabled="" 或 disabled="false" —— 只要属性存在，浏览器就视为禁用；但若 JS 动态设为 el.disabled = false，反而会覆盖父级继承，导致“该禁没禁”
• label 的 for 指向了 fieldset 外的 input，点击 label 实际触发的是外部控件
• 控件不在 fieldset DOM 子树中：比如用了 position: absolute 移出视觉区域但未脱离文档流，或用了 display: contents 破坏父子关系
• 框架（Vue/React）或 Web Components 封装后，底层节点脱离原生继承链，fieldset 的禁用信号无法触达

动态控制时该用 .disabled = true 还是 removeAttribute

必须统一用属性赋值方式，避免兼容性断裂：

• 启用：document.querySelector('fieldset').disabled = false
• 禁用：document.querySelector('fieldset').disabled = true
• 别用 setAttribute('disabled', '')：老 Safari 中可能不触发底层状态更新
• 别用 removeAttribute('disabled')：IE ≤ 11 和 Safari ≤ 15.6 中常不重绘 UI，控件看起来灰显但实际可交互
• el.disabled = null 或 undefined 不会清除禁用状态，只认布尔值

禁用后值还提交吗？怎么判断真实禁用状态

禁用后，所有受影响控件的值不会出现在 FormData 或 form.submit() 请求体中，和单个 input 加 disabled 行为一致。但仅靠 el.disabled 无法判断是否被父级继承禁用：

• 用 el.matches(':disabled') —— 返回 true 表示当前不可交互（含继承），现代浏览器全支持
• 若需兼容 Safari ≤ 15.3 或 IE，得手动向上遍历：el.parentElement 是否为 disabled 的 fieldset
• 注意：如果某个 input 被误加了 readonly，它的值反而会提交，造成数据不一致

复杂点在于禁用状态和可访问性、键盘焦点、框架响应之间的耦合。哪怕 DOM 正确设置了 disabled，若 legend 里塞了控件、或用了 display: contents、或 React 组件没透传 disabled，行为就会断裂。