optgroup 是 select 元素内用于语义化归类 option 的容器标签，必须作为 select 的直接子元素，不可嵌套或脱离 select 使用，其核心价值在于提升可访问性与屏幕阅读器支持。
optgroup 本身不是用来“分组下拉选项”的独立功能，而是 select 元素内用于语义化归类 option 的容器标签。它不改变渲染逻辑，但直接影响可访问性、键盘导航和屏幕阅读器行为。
为什么 optgroup 必须嵌在 select 里
浏览器只在 select 上下文中识别 optgroup；把它放在 div 或表单其他位置会直接被忽略，DOM 中可能保留但无任何语义或交互效果。常见错误是误以为它可以配合 ul/li 模拟下拉——不行，那属于自定义组件范畴，和原生 optgroup 无关。
-
optgroup只能作为select的直接子元素，不能嵌套在另一个optgroup里 -
label属性是必需的，否则该分组不会显示标题（且部分旧版 Safari 会跳过整个节点） - 所有
option必须在optgroup内或select直接子级，不能混排：比如option→optgroup→option是非法结构
optgroup 和 ul/ol 列表的本质区别
ul 和 ol 是通用内容列表，用于页面上可见的、可滚动的并列/有序信息流；optgroup 是表单控件内部的语义分组机制，不生成独立 DOM 节点，也不参与 CSS 布局流（例如不能给它设 margin 或 display: flex）。它的唯一作用是告诉浏览器：“这些 option 属于同一逻辑类别”。
- 用
ul展示“产品分类导航”？可以，也推荐 - 用
optgroup实现“选择商品分类”下拉？必须，否则辅助技术无法感知分组意图 - 想让下拉里某组选项禁用？只能对每个
option单独加disabled，optgroup自身不支持disabled属性（Chrome 会忽略，Firefox 表现不一致）
长列表中 optgroup 的性能与可维护陷阱
当 option 数量超过 200 条时，单纯靠 optgroup 分组并不能缓解渲染卡顿——浏览器仍需一次性解析全部 HTML 节点。真正影响体验的是 DOM 构建方式，而非分组标签本身。
立即学习“前端免费学习笔记（深入）”；
- 服务端渲染大量
option？考虑分页加载 + 搜索过滤，而不是堆满optgroup - 用 JS 动态插入？避免循环拼接字符串后
innerHTML注入，改用document.createDocumentFragment()批量挂载 -
optgroup的label文本别用空格或不可见字符填充对齐——屏幕阅读器会逐字读出，破坏语义 - 不要为了视觉对齐在
label里塞 或text-indent或伪元素控制缩进
最常被忽略的一点：optgroup 的语义价值只在用户使用键盘（Tab + 方向键）或屏幕阅读器时才完全释放。纯鼠标点击场景下，它看起来只是个灰色标题——但这恰恰是它存在的全部意义。
