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 控制。
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
-
div、span、p等非表单元素加了disabled属性也无效，浏览器直接忽略 -
contenteditable="true"的元素（如div contenteditable）不会被禁用，fieldset对它无控制力 - 自定义组件（如 Vue 封装的
<my-input></my-input>、React 的<input>）若未将disabled透传到底层原生input，就会逃逸禁用逻辑 - 通过 JavaScript 绑定的
click或input事件，只要没显式检查fieldset.disabled，依然会执行——禁用只拦截原生行为
权限控制场景下必须绕开的坑
用 fieldset disabled 做前端权限隔离很省事，但容易在真实业务中翻车：
立即学习“前端免费学习笔记（深入）”；
- 服务端绝不能依赖这个禁用状态做权限判断——删掉
disabled属性或手动发请求就能绕过，后端必须校验字段可写性 - 如果需要“保留值但禁止编辑”，别用
disabled，改用readonly+ CSS（如pointer-events: none）+ 移除tabindex，否则提交时字段丢失 - 嵌套
fieldset无法“取消”外层禁用：外层disabled，内层即使写<fieldset></fieldset>也不恢复可用——禁用是单向继承，不可逆 - IE11 和 Safari ≤ 15.6 不支持
fieldset disabled，需降级 fallback：用 JS 遍历并设el.disabled = true，或用hasAttribute("disabled")检测兼容性
真正麻烦的不是怎么禁用，而是禁用后用户还能不能通过键盘 Tab 进入区域、屏幕阅读器是否准确播报、以及后端有没有同步校验逻辑——这些点一旦漏掉，权限控制就只剩个样子。
