safari 16 及更早版本不支持 ，因其未被 html 规范强制要求；需手动禁用每个 并配合 css 弱化视觉，同时后端必须校验提交值。
直接给 <optgroup></optgroup> 加 disabled 属性就能禁用整组，但 Safari 16 及更早版本不支持——它会完全忽略这个属性，组内 <option></option> 依然可点、可键盘聚焦、可提交。
为什么 optgroup disabled 在 Safari 里失效
这不是 bug，是 HTML 规范没强制要求浏览器实现 <optgroup disabled></optgroup>。Chrome/Firefox/Edge 都支持，Safari 直到 17 才真正落地。如果你的用户包含 iOS 16 或 macOS Monterey 用户，就得绕开它。
- 现象：加了
disabled的<optgroup></optgroup>在 Safari 里 label 还能被 Tab 键聚焦，方向键仍可选中内部<option></option> - 根本原因：Safari 不把
<optgroup disabled></optgroup>当作禁用信号，只当普通分组渲染 - 后果：前端 UI 看似“禁用了”，但用户真能选、JS 能读到值、后端可能收到非法值
安全写法：手动禁用每个 option + 隐藏 optgroup label
要全平台一致禁用整组，必须放弃依赖 <optgroup disabled></optgroup>，改用显式控制每个 <option></option>，再配合 CSS 弱化视觉干扰：
- 给该组下所有
<option></option>都加上disabled（只写disabled，别写disabled="true"） - 用 CSS 把
<optgroup></optgroup>的 label 文字颜色调灰：optgroup { color: #999; } - 如果想彻底隐藏 label，不能用
display: none（会删掉整个节点），可用visibility: hidden或font-size: 0+line-height: 0 - JS 动态操作时，别只遍历
select.options，先定位到<optgroup></optgroup>元素，再用optgroup.children获取其子<option></option>
JS 判断某个 option 是否真能被选中
前端禁用只是表层限制，JS 逻辑里不能只看 option.disabled 就认定它无效——因为它的父级 <optgroup></optgroup> 可能也被禁用了（在支持的浏览器里），或者你手动禁用了它但忘了同步状态。
- 正确判断方式：
!option.disabled && !option.parentElement?.disabled - 错误写法：
option.getAttribute('disabled') === 'true'—— 返回""或null，语义模糊 - 注意：
select.options始终包含所有<option></option>，哪怕它们在被禁用的<optgroup></optgroup>里，DOM 结构没变
什么时候不该用 optgroup disabled
即使浏览器支持，<optgroup disabled></optgroup> 也不适合所有场景：
- 需要隐藏整组（不只是置灰）：它仍占布局空间，label 也可见，用 JS 移除节点更干净
- 分组内容随权限动态变化：比如“管理员专区”只对部分用户显示，这时应服务端不输出该
<optgroup></optgroup>，而非前端禁用 - 组内只有个别选项需禁用：直接给对应
<option disabled></option>即可，动<optgroup></optgroup>反而误导用户
最常被忽略的一点：禁用只是 UI 层的事，后端永远要校验提交的 value 是否属于当前用户允许的范围——哪怕前端看起来“完全不可选”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
