fieldset的disabled属性会递归禁用内部所有原生表单控件（input、textarea、select、button、output及嵌套fieldset），但不作用于legend、div、span、contenteditable元素及未透传disabled的自定义组件。

fieldset 的 disabled 属性会递归禁用其内部所有原生表单控件，但不是“全部子元素”——它只影响特定类型，且有明确例外。

哪些子元素会被 fieldset disabled 真正禁用

浏览器原生支持的可交互表单控件才会被继承禁用，包括：input、textarea、select、button、output，以及嵌套在其中的其他 fieldset（会继续向下递归）。只要这些元素位于 fieldset 的 DOM 子树中（哪怕中间隔着 div、section 或 label），都会被禁用。

• 禁用效果是行为级的：失去焦点能力、无法输入/点击、不响应 change/input 事件
• 提交时，这些控件的值**完全不会出现在 FormData 或 form.submit() 请求体中**，和单个 input disabled 行为一致
• 即使子控件写了 disabled="false" 或空字符串 disabled=""，也无效——父级 disabled 强制覆盖

哪些子元素完全不受影响

legend 是唯一被规范明确排除的元素：它的文本仍可聚焦、可选中、可被屏幕阅读器读出，且内部任何内容（比如 legend 里写的 input）都不受父 fieldset disabled 控制。

财经HTML高端海报生成

复杂得财经如何变成清晰，适合手机看的海报？如何加上你的IP

下载

• div、span、p 等非表单元素加了 disabled 属性也无效，浏览器直接忽略
• contenteditable="true" 的元素（如 div contenteditable）不会被禁用，fieldset 对它无控制力
• 自定义组件（如 Vue 封装的 、React 的 ）若未将 disabled 透传到底层原生 input，就会逃逸禁用逻辑
• 通过 JavaScript 绑定的 click 或 input 事件，只要没显式检查 fieldset.disabled，依然会执行——禁用只拦截原生行为

权限控制场景下必须绕开的坑

用 fieldset disabled 做前端权限隔离很省事，但容易在真实业务中翻车：

• 服务端绝不能依赖这个禁用状态做权限判断——删掉 disabled 属性或手动发请求就能绕过，后端必须校验字段可写性
• 如果需要“保留值但禁止编辑”，别用 disabled，改用 readonly + CSS（如 pointer-events: none）+ 移除 tabindex，否则提交时字段丢失
• 嵌套 fieldset 无法“取消”外层禁用：外层 disabled，内层即使写
  也不恢复可用——禁用是单向继承，不可逆
• IE11 和 Safari ≤ 15.6 不支持 fieldset disabled，需降级 fallback：用 JS 遍历并设 el.disabled = true，或用 hasAttribute("disabled") 检测兼容性

真正麻烦的不是怎么禁用，而是禁用后用户还能不能通过键盘 Tab 进入区域、屏幕阅读器是否准确播报、以及后端有没有同步校验逻辑——这些点一旦漏掉，权限控制就只剩个样子。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！