不能无条件批量禁用——它只对原生可提交控件（input/select/textarea/button/output）生效，受显式属性、DOM结构和框架封装三重限制；legend内控件始终可操作，自定义组件、contenteditable及显式设disabled的子元素不受影响。
fieldset disabled 能否真正批量禁用所有子表单项
不能无条件批量禁用——它只对原生可提交控件生效，且受显式属性、DOM 结构和框架封装三重限制。
生效范围明确：仅 input、select、textarea、button、output 这五类元素会继承禁用状态；其他如 label、div、span、contenteditable 元素完全不受影响。
-
legend内的任何控件（比如<legend><input type="checkbox">同意条款</legend>）始终可操作，这是 HTML 规范强制行为 - 子元素若显式写了
disabled=""或disabled="false"，浏览器仍解析为禁用，且优先级高于父级fieldset—— 不是“覆盖”，而是“已声明” - React/Vue 封装的自定义组件（如
<MyInput>）若未将disabled透传到底层input，禁用就失效
为什么加了 disabled 的 fieldset，某些 input 还能点、能提交
不是属性没起作用，而是被绕过了原生禁用机制。
-
label的for属性指向了fieldset外的inputID，点击 label 实际激活的是外部控件 - 用了
display: contents或position: absolute导致 DOM 子树断裂，浏览器无法识别父子关系 - JavaScript 直接调用
el.click()或el.focus()，禁用只拦截用户交互，不阻止 JS 执行 - 表单提交时发现字段值缺失：因为
fieldset[disabled]下的控件值默认不参与序列化（FormData、form.elements遍历中el.disabled === true，但不会发给后端）
动态控制 fieldset.disabled 的正确写法
必须用属性赋值，而非字符串操作。现代浏览器中 el.disabled = true/false 是唯一可靠方式。
立即学习“前端免费学习笔记（深入）”；
- ✅ 正确：
document.querySelector('fieldset').disabled = true—— 立即触发状态同步与样式更新 - ❌ 错误：
el.setAttribute('disabled', '')—— 只加属性字符串，旧 Safari/IE 可能不触发底层状态 - ❌ 错误：
el.removeAttribute('disabled')—— 在 Safari ≤15.6 中可能视觉灰显但实际可交互 - 服务端渲染建议用
disabled="disabled"，比disabled=""更兼容 XHTML 场景
fieldset disabled 和 readonly 的根本区别
别混用。二者语义、行为、提交逻辑完全不同。
-
fieldset[disabled]→ 所有子控件不可聚焦、不可编辑、值**不提交** -
readonly→ 仅对input和textarea有效，允许聚焦、可复制、值**必须提交** -
select不支持readonly，强行加无效；需用disabled+ 额外div显示当前值来模拟只读 - 如果业务需要“内容可见+值必传+禁止编辑”，
fieldset[disabled]是错的，该用readonly+ CSS 禁用指针 + 键盘拦截
最常被忽略的是键盘 Tab 顺序和读屏播报：fieldset 的语义价值不在灰显效果，而在 DOM 分组结构是否真实反映焦点流和可访问性意图。
