label属性仅影响屏幕阅读器播报，不改变视觉显示；其优先级低于aria-label，为空时可能导致跳过，且对表单提交和JS获取值无任何影响。
option 的 label 属性不是用来“显示文字”的
很多人以为 label 是给下拉选项加个“别名”或“简短描述”，实际它只影响 可访问性层面对屏幕阅读器的播报内容，不改变视觉渲染。浏览器渲染时，<option> 显示的文字永远是它的文本节点内容（即标签内写的字），label 值不会出现在界面上，也不会覆盖它。
label 属性在 aria-label 和 screen reader 中的优先级很特殊
当 <option> 同时存在 label 属性和文本内容时，主流屏幕阅读器（如 NVDA、VoiceOver）会优先读 label 的值；但如果还设置了 aria-label，则 aria-label 会覆盖 label —— 这点容易被忽略，且没有规范明确定义优先级顺序，实测中 Chrome + NVDA 下 aria-label 确实胜出。
-
label存在但为空（label=""）：部分读屏器会跳过该选项，或回退读文本内容 -
label值含空格或换行：会被标准化为单空格分隔，不影响播报但可能影响语义清晰度 - 未设
label：完全依赖文本内容，对多语言或缩写场景不友好（比如<option value="en">EN</option>，读屏器就只读“EN”）
label 在表单提交和 JS 获取值时完全不参与
label 属性对任何运行时行为都无影响：它不出现在 FormData 中，select.value 或 select.options[i].value 都取不到它，select.selectedOptions[0].getAttribute('label') 才能手动读取。常见误用是以为设置 label 就能替代 value，其实两者职责完全不同：
-
value→ 提交给后端的数据（必须有，否则 fallback 到文本内容） -
label→ 仅用于辅助技术播报（可选，纯前端无障碍增强） - 文本内容 → 视觉显示 +
value的 fallback + 读屏器兜底播报
label 的兼容性坑比想象中多
虽然所有现代浏览器都支持 label 属性解析，但 Firefox 直到版本 11 才开始支持（旧资料里常写“Firefox 2+”，那是错的），而 Safari 在某些 macOS VoiceOver 组合下会忽略空格开头的 label 值。更隐蔽的问题是：如果 <optgroup> 被禁用（disabled），其内部 <option> 的 label 仍会被读屏器读出——但用户无法选择，这会造成语义矛盾。
立即学习“前端免费学习笔记（深入）”；
真正关键的细节是：label 不继承、不可脚本化修改后实时生效（改了 DOM 属性，读屏器不会重读），而且它不能包含 HTML 实体以外的任何标记。写 <option label="<strong>危险</strong>">删除</option>，读屏器只会念“危险”，而非加粗效果。
