最常见原因是子元素显式声明disabled属性（如disabled=""或disabled="false"），浏览器以子元素为准，父级fieldset无法覆盖；其次控件不在其DOM子树内（如label for指向外部input）导致绕过禁用。
fieldset disabled 为什么没让所有 input 失效
最常见原因是子元素自己写了 disabled 属性，比如 <input disabled="false"> 或 <input disabled=""> —— 只要属性存在，浏览器就视为禁用，父级 fieldset 的禁用状态不会覆盖它。另一个高频漏点是：控件不在 fieldset 的 DOM 子树里，比如 <label for="name"> 指向的是 fieldset 外的 <input id="name">，点击 label 就绕过了禁用逻辑。
检查是否生效的最快方式：
- 打开开发者工具，选中某个 input，看 element.matches(':disabled') 是否返回 true
- 如果返回 true 但 element.hasAttribute('disabled') 是 false，说明禁用来自父级 fieldset
- 如果 input 仍可 Tab 进去，说明它脱离了继承链（比如被 <div> 包裹后又没设 role="none"）
如何安全地用 JS 切换 fieldset 的禁用状态
直接操作 disabled 属性最可靠：
- 启用：document.querySelector('fieldset').disabled = false
- 禁用：document.querySelector('fieldset').disabled = true
别用 setAttribute('disabled', '') 或 removeAttribute('disabled')，前者在旧 Safari 中可能不触发底层状态更新，后者在 IE ≤ 11 和 Safari ≤ 15.6 中常不重绘 UI。
- 如果禁用前该 fieldset 内有元素聚焦，禁用后焦点不会自动移走，得手动 nextFocusable.focus()
- Vue/React 场景下，仅改 DOM 不够，必须同步更新组件 state，否则下次 re-render 会把 disabled 属性刷掉
fieldset disabled 和 readonly 的根本区别在哪
不是“能不能输”的问题，而是“要不要提交”的问题：
- fieldset[disabled] 下所有子控件的值**不会出现在 FormData 或表单提交请求体中**
- readonly 只对 <input> 和 <textarea> 有效，且值照常提交；<select>、<checkbox> 加 readonly 完全无效
- 若业务要求“内容可见、可复制、值必须传”，就得用 readonly + CSS 配合（如 pointer-events: none），而不是 disabled
- 混用两者极易导致后端收不到字段：比如地址块用 fieldset[disabled]，但里面某个 input 被误加了 readonly，它的值反而会提交，造成数据不一致
兼容性兜底和无障碍必须注意的点
Safari ≤ 15.6 和 IE 完全不支持 fieldset[disabled]，必须 fallback：
- 检测：if (!('disabled' in document.createElement('fieldset')))
- 兜底方案：JS 遍历所有子表单控件，逐个设 el.disabled = true
- <legend> 必须存在且为第一子元素，否则禁用继承失效，屏幕阅读器也读不出分组语义
- 别给 fieldset 加 aria-disabled="true"，和原生 disabled 共存会导致读屏软件重复播报
- 收起/展开分组时，禁用状态下别用 display: none，否则整个区域对键盘和读屏器不可见，要用 inert 属性配合 aria-expanded
