label的for属性必须严格匹配input的id值，大小写、连字符、顺序均需完全一致；id须以字母开头、全局唯一、不可为纯数字或含点号/冒号，且必须在dom中同步存在。
label的for属性必须严格匹配input的id值
这是表单可访问性的基础，不是“建议”而是强制要求。浏览器和读屏器只认for与id字符级完全一致——大小写、连字符、顺序，一个都不能错。
-
for="email-input"必须对应<input id="email-input">；写成id="Email-input"或id="email_input"都会断开关联 - 服务端模板或JS动态渲染时，容易漏掉拼接逻辑：比如后端传入
user_id=1001，但前端写成了id="email-{{user_id}}"却忘了同步改for="email-{{user_id}}" - Vue/React 中用
:for="`email-${id}`"时，确保id是字符串类型，数字型1001直接拼接不会报错，但可能被误解析为其他含义（如 CSS 选择器中的数字前缀）
id不能是纯数字或以数字开头
看似合法的 id="123" 在实际工程中就是隐患。CSS 里要写成 # 23（转义），JS 虽能 getElementById("123") 取到，但 querySelector("#123") 会失败——因为浏览器把它当成了伪类或非法选择器。
- 正确写法只有小写字母开头 + 连字符组合：
id="user-123"、id="field-age" - 禁止使用点号、冒号：
id="user.email"会导致querySelector("#user.email")查找 class="email" 的元素，而非 id - SSR 场景下，服务端生成
id="user-123"，客户端 hydration 时若因状态不一致改成了id="user-456"，a11y 树首次构建就会失效，Lighthouse 会直接标红
多个label指向同一个input时，id仍是唯一锚点
一个 <input id="search"> 可以被多个 <label for="search"></label> 关联，这是合法且常见的（比如搜索框上方标题 + 右侧按钮都作为 label）。但反过来说，id 本身仍必须全局唯一——你不能让另一个 input 也叫 id="search"。
- 错误模式：
<input id="search">和<button id="search"></button>共存 → JSgetElementById("search")永远只返回第一个，第二个彻底不可达 - ARIA 场景下，
aria-labelledby="search-hint search-label"依赖的每个 ID 都得真实存在且唯一；若其中search-hint不存在，整个标签关联就静默失效，无报错提示 - 表格内嵌表单时尤其危险：比如每行有个操作按钮
<button id="delete-btn"></button>，循环渲染却没加后缀 → 所有按钮共用同一 id，JS 事件只绑在第一行
用id做表单语义关联，别碰class或data-*替代
for 属性只认 id，这是 HTML 规范硬性约定。试图用 class="email-field" 或 data-field="email" 来“模拟” label 关联，只会让屏幕阅读器完全忽略输入项的说明文字。
- 辅助技术（NVDA、VoiceOver）不读
class，也不解析data-，它们只依赖for→id这条链路 - 如果真需要多层语义（比如一个字段同时属于“用户信息”和“必填项”），用
aria-labelledby组合多个id，而不是塞进class里 - 前端框架里，别为了“统一管理”把所有表单控件的 id 都设成
id="{{name}}-input"就完事——name 重复（如多个复选框都叫hobby）会导致 id 冲突，必须加唯一上下文，例如id="hobby-music-input"
id 的语义效力完全依赖 DOM 存在时机。哪怕 <label for="xxx"></label> 先挂载，只要 <input id="xxx"> 是异步插入或条件渲染（比如 v-if 或 {show && <input>}），在那一瞬间，无障碍树就无法建立连接——不是 bug，是规范如此。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
