<fieldset> 和 <legend> 能真正实现语义化分组，使屏幕阅读器、自动化工具和表单 API 识别逻辑关系；它具备禁用子元素、提供可访问标题、保障表单行为等原生能力，远超视觉容器。
用 <fieldset> 和 <legend> 能真正实现语义化分组，不是视觉“看起来像一组”，而是让屏幕阅读器、自动化测试工具、浏览器表单 API 都识别出逻辑分组关系。
为什么 <fieldset> 不是“加个边框”那么简单
很多人只把它当 CSS 容器用，结果删掉样式后结构就塌了。实际上：<fieldset> 会自动禁用内部所有可交互元素（包括 <input>、<select>、<button>），只要它自己带 disabled 属性；而普通 <div> 做不到这点。更重要的是，<legend> 是唯一被规范指定为 <fieldset> 的**可访问标题**——它会被读屏软件作为该组字段的说明朗读出来，且必须是 <fieldset> 的第一个子元素。
<legend> 必须紧贴 <fieldset> 开头，且不能嵌套其他标签
常见错误是写成：<legend><h3>收货信息</h3></legend> 或 <legend><span class="label">支付方式</span></legend>。这会导致：
- 部分读屏软件跳过
<h3>或<span>，只读纯文本（甚至不读） - Chrome 浏览器在
<legend>内使用<div>会直接破坏渲染布局 - WCAG 2.1 检查失败：要求
<legend>文本必须可程序化获取，不能被包裹干扰
正确写法就是：<legend>配送时间偏好</legend> —— 纯文本，无内嵌标签，无空格占位符。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
和 aria-labelledby / aria-label 的关键区别在哪
有人试图用 <div aria-labelledby="group-label"> 替代 <fieldset>，这是错的：
-
aria-labelledby只影响可访问性名称，不改变 DOM 结构或表单行为 - 它不会继承
disabled状态，内部<input>依然可聚焦、可提交 - JavaScript 获取
form.elements时，<fieldset>分组下的字段仍属于表单，但用div+ ARIA 就完全丢失语义关联 - 移动端键盘弹出逻辑、自动填充（autofill）提示也依赖原生
<fieldset>分组
示例对比：
<fieldset disabled><br> <legend>发票信息</legend><br> <input name="invoice_title"><br></fieldset>→ 整组不可操作；
<div aria-labelledby="inv-label"><br> <span id="inv-label">发票信息</span><br> <input name="invoice_title"><br></div>→ 输入框依然能点、能输、能提交。
兼容性和性能几乎零成本，但漏掉就埋雷
<fieldset> 和 <legend> 在所有现代浏览器中支持完好（IE9+），没有 polyfill 需求。但它容易被忽略的点是：
- 服务端渲染（SSR）模板里，如果条件渲染字段组，忘了同步控制
<fieldset>的开闭，会导致 DOM 结构断裂（比如</fieldset>缺失） - React/Vue 中动态插入字段时，若用
v-for或{list.map()}直接生成<input>，没包在<fieldset>里，就等于放弃分组语义 - 表单校验库（如 Formik、VeeValidate）默认不感知
<fieldset>，需手动把分组错误消息挂到<legend>后或用aria-describedby关联
真正麻烦的从来不是怎么写，而是写完之后没人再检查它是否还在起作用 —— 尤其是改版、重构、A/B 测试时，<fieldset> 最先被当成“装饰”删掉。
