fieldset 是表单逻辑分组的语义基石，必须配非空 legend 作首个子元素，disabled 仅作用于直接子级表单控件，支持 form 属性跨父表单关联，核心价值在于可访问性、键盘导航与原生表单行为支撑。
fieldset 不是用来“加个边框”的视觉容器，它是表单逻辑分组的语义基石。漏掉 legend、位置写错、或只当 div 用，等于白写——屏幕阅读器读不出组名，键盘导航断层，disabled 行为失效，表单验证和自动填充都可能出问题。
为什么 legend 必须是 fieldset 的第一个子元素且不能空
浏览器和读屏软件靠 legend 文本识别这组控件的用途，它不是装饰，而是可访问性名称的唯一来源。
- 空
<legend></legend>会被播报为“空白分组”，比不写更误导用户；应写成<legend>收货地址</legend> -
<legend><h3>收货地址</h3></legend>会干扰名称获取，部分读屏器跳过h3或直接静音 -
<fieldset> <input><legend>收货地址</legend> </fieldset>—— 语义断裂，Chrome 和 NVDA 可能完全忽略该组 - 视觉隐藏但保留语义？用
position: absolute; clip: rect(1px, 1px, 1px, 1px);，禁用display: none或visibility: hidden
fieldset[disabled] 真实禁用的是什么，又不作用于什么
加 disabled 属性不是加灰样式，而是触发原生表单行为：所有**直接子级**标准表单控件自动失效、无法聚焦、提交时值被排除。
- 生效范围：直接子级的
<input>、<select></select>、<textarea></textarea>、<button></button>、<input type="radio">组 - 不生效范围：
<div> 里嵌套的 <code>input、contenteditable元素、自定义 Web Component（除非它们主动监听fieldset状态） -
label点击行为在 Chrome 和 Firefox 中不一致：Chrome 允许穿透到内部控件（即使 disabled），Firefox 拦截，必须真机测试 - 被禁用的控件值不会出现在
FormData中；若业务要求提交，需 JS 手动补全，例如formData.append('email', input.value) - 优先用单层
fieldset分组，靠 CSS（如margin、border-bottom）做视觉分隔 - 若必须嵌套，确保每层都有语义清晰的
<legend></legend>，且legend内不放交互元素（如<button></button>） - UI 框架（如 Ant Design、Bootstrap）常剥离
fieldset，仅保留视觉结构；务必检查渲染后 DOM，确认fieldset和legend真实存在 - 用
document.activeElement+console.log实时观察焦点路径，比依赖默认行为更可靠 - 写法：
<fieldset form="myForm"> <legend>发票信息</legend> <input name="invoice_title"> </fieldset>+<form id="myForm">...</form> - 注意：
form属性只影响表单关联，不影响disabled传递或可访问性；禁用仍需直接作用于该fieldset - 多个
fieldset可共用一个form属性值，适合模块化表单组装场景 - 不支持 IE11 及更早版本，现代项目基本无碍，但需留意兼容性矩阵
嵌套 fieldset 的实际风险与替代方案
嵌套本身合法，但深层嵌套（≥3 层）极易破坏键盘 Tab 导航流，尤其当内层 legend 缺失或被隐藏时，焦点可能“卡住”在某一层出不来。
form 属性让 fieldset 脱离父 form 标签也能参与提交
当业务需要把一组控件（比如动态插入的地址模块）放在 <form></form> 外部时，fieldset 的 form 属性就是解法——它显式绑定所属表单 ID，让这些控件仍能被 form.elements 收集、参与序列化和提交。
最常被忽略的点：很多开发者调完样式就以为完成了，但 fieldset 的核心价值不在边框，而在它对表单逻辑、键盘导航边界、批量禁用和可访问性名称的原生支撑——这些能力一旦缺失，修复成本远高于初期规范书写。
