fieldset 的 disabled 仅作用于直系表单控件，非直接子元素（如 div 包裹）将中断禁用传递；legend 必须为首子节点、非空且语义明确；嵌套需谨慎，避免焦点与验证异常；disabled 控件值不提交，但需手动添加样式反馈。
fieldset 不是视觉容器，它的验证逻辑和交互行为由浏览器原生控制，但极易因结构错误失效。关键不在“加不加”，而在“怎么嵌、怎么禁、怎么读”。
为什么 fieldset 上加 disabled 却没禁用子控件
最常见原因是子控件不是 fieldset 的**直接子元素**。浏览器只把 disabled 传递给直系表单控件（input、select、textarea、button、input[type="radio"] 等），中间插一层 div 或 section 就断链。
典型失效写法：
修复方式：
- 删掉包裹的
div，让input成为fieldset的第一个子节点 - 若需布局控制，改用
span或 CSS Grid/Flex 容器（它们不影响语义继承） - 用键盘 Tab 测试：焦点不该停在任何被禁用的控件上，这是唯一可靠验证方式
legend 为空或位置错会导致验证逻辑异常
legend 不只是标题，它是可访问性树中该组的唯一标识。空 <legend></legend>、display: none 隐藏、或放在 fieldset 中间，都会让屏幕阅读器读作“未命名组”，且部分浏览器（Chrome/Firefox）会忽略其边框渲染，disabled 继承也失效。
必须满足的三个硬条件：
-
legend是fieldset的**首个子节点**，不能前面有注释、空格或文本节点 - 内容非空，且具业务含义，如
<legend>收货信息</legend>，而非<legend>选项</legend> - 视觉隐藏只能用
position: absolute; clip: rect(1px, 1px, 1px, 1px)，禁用display: none和visibility: hidden
嵌套 fieldset 时验证和焦点流容易失控
HTML 允许嵌套，但实际验证逻辑只检查 fieldset 的直属子控件。比如 checkValidity() 不会递归进内层 fieldset，而屏幕阅读器对 ≥3 层嵌套的支持极差，焦点可能卡在中间层出不来。
真实开发中应避免的模式：
- 用
aria-labelledby替代legend——它不触发disabled继承，也不影响焦点顺序 - 在嵌套
fieldset内放button或a——这些元素会打断键盘导航流 - 依赖框架（如 Ant Design）自动补
legend——上线前必须检查真实 DOM，很多 UI 库会剥离它
推荐做法：优先单层 fieldset + CSS 边框/间距做视觉分隔；必须嵌套时，每层都带非空 legend，且内层不放可聚焦元素。
表单提交时 fieldset[disabled] 的值是否真的不提交
是的，只要结构正确，被 disabled 的 input、select 等直系控件的值**不会出现在 FormData 中，也不会随表单提交**。但有两个例外要注意：
-
button[type="submit"]在旧版 Chrome/Firefox 中可能仍触发提交，建议统一用button[type="button"]+ JS 控制 -
fieldset自身没有name，它不参与数据提交，只起控制作用；别指望它像input那样传值
真正容易被忽略的是样式反馈：fieldset[disabled] 不会自动灰掉文字颜色，需手动加 CSS：fieldset[disabled] { opacity: 0.6; }，否则用户可能误以为还能操作。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
