html中的disabled属性部分生效：视觉禁用且键盘不可选，但鼠标点击仍可选中，提交时值可能被带上；需结合js监听change事件主动还原，并后端校验。
HTML 中 <option></option> 的 disabled 属性是否生效？
直接加 disabled 到 <option></option> 是有效的，但仅限于视觉禁用和键盘不可选——它**不会阻止鼠标点击选中**（尤其在 Chrome/Firefox 中），且表单提交时该值仍可能被带上（取决于浏览器行为）。这不是 bug，而是 HTML 规范允许的“部分禁用”：选项不可聚焦、不可通过键盘导航选中，但鼠标点击仍可触发选择。
为什么 disabled 在某些场景下像没起作用？
常见错觉来源：
- 用户用鼠标点了一下被标
disabled的<option></option>，结果还是选中了（尤其在快速点击或未刷新渲染时） - 后端收到该
<option></option>的value，误以为前端控制失效 - 用了 JS 动态设置
option.disabled = true，但未同步更新<select></select>的当前selectedIndex或触发重渲染
真正可靠的禁用方式：结合 disabled + change 监听 + 主动还原
单纯依赖属性不够，需配合 JS 控制逻辑流。核心思路是：允许 DOM 层面的 disabled（防键盘/焦点），但拦截非法选择并立即回退。
示例：
<select id="mySelect"><option value="a">选项 A</option> <option value="b" disabled>选项 B（禁用）</option> <option value="c">选项 C</option></select>
对应 JS：
const sel = document.getElementById('mySelect');
const disabledValue = 'b';
sel.addEventListener('change', () => {
if (sel.value === disabledValue) {
// 立即还原为上一个有效值（比如上次合法选中的值）
// 或设为默认空值：sel.selectedIndex = 0;
sel.value = ''; // 假设第一项是 placeholder
}
});
注意点：
- 必须监听
change，不是click或input（<select></select>不触发input） - 若支持多选（
multiple），需遍历sel.selectedOptions过滤掉disabled项 - 服务端永远不能信任前端禁用，必须二次校验
value是否在允许列表内
React/Vue 等框架中更推荐用状态驱动而非原生 disabled
框架里硬塞 disabled 到 <option></option> 容易和虚拟 DOM 更新冲突（比如重新 render 后 disabled 被覆盖）。更稳的做法是：从选项数组中过滤掉禁用项，或用 disabled + key 强制重置。
例如 React：
const options = [
{ value: 'a', label: '选项 A' },
{ value: 'b', label: '选项 B', disabled: true },
{ value: 'c', label: '选项 C' }
];
return (
<select onchange="{handleChange}">
{options.map((opt) => (
<option key="{opt.value}" value="{opt.value}" disabled>
{opt.label}
</option>
))}
</select>
);
但关键仍在 handleChange 里做值校验——框架不改变浏览器对 disabled 的宽松执行逻辑。
禁用选项这件事，表面是加个属性，实际是前后端共同约定的校验链。DOM 层的 disabled 只是第一道提示，JS 层的拦截和后端的兜底才是真正的防线。
