禁用下拉框应使用disabled属性：作用于可完全禁用交互与提交，作用于仅禁用该选项；readonly无效，css伪禁用不安全且无障碍不友好。
用 disabled 属性禁用整个下拉框最直接
给 <select></select> 标签加上 disabled，它就完全不可交互：不能点击、不能聚焦、不能通过键盘切换选项，表单提交时该字段也不会被发送。
常见错误是只加 readonly——<select></select> 不支持这个属性，加了也无效，浏览器会忽略。
示例写法：
<select name="status" disabled><option value="pending">待处理</option> <option value="done">已完成</option></select>
- 注意：
disabled元素默认灰显，样式可覆盖，但语义上仍是“禁用” - 如果需要保留视觉样式（比如和旁边正常控件一致），得额外用 CSS 强制重置颜色、背景等
- 服务端接收时，
disabled字段根本不会出现在request.body或FormData中，别指望它传值
只禁用某几个 <option></option> 而非整个下拉框
在特定 <option></option> 上加 disabled，它就会变灰且无法被选中，但其他选项仍可用。
典型场景：保留“请选择”提示项为禁用状态，同时允许用户从后续有效项中选择。
示例写法：
<select name="city"><option value="" disabled selected>请选择城市</option> <option value="bj">北京</option> <option value="sh" disabled>上海（暂不开放）</option> <option value="gz">广州</option></select>
-
disabled的<option></option>不会出现在select.options的可选集合里，JS 遍历时会被跳过 - 用户用键盘操作时，焦点会自动跳过被
disabled的项，这点比单纯用 CSS 隐藏更可靠 - 别混淆
disabled和hidden：hidden只影响渲染，不影响表单逻辑；disabled才真正切断交互与提交
用 JavaScript 拦截选择行为但不设 disabled
有些场景要求视觉上看起来“可点”，但实际禁止更改——比如已提交后锁定选项。这时不能用 disabled，否则 UI 失去一致性。
核心思路是监听 change 事件并立即还原原值，或阻止默认行为 + 手动重置。
示例逻辑：
const select = document.querySelector('select[name="role"]');
const originalValue = select.value;
select.addEventListener('change', () => {
select.value = originalValue;
select.dispatchEvent(new Event('input', { bubbles: true }));
});
- 仅靠
preventDefault()在change里无效，因为 change 是“已发生后触发”的，必须手动回填 - 如果用户用键盘操作（方向键+回车），还得监听
keydown并对Enter、Space等做拦截 - 这种做法对屏幕阅读器不友好，辅助技术可能误判为可交互控件，应配合
aria-disabled="true"声明状态
为什么不用 pointer-events: none 或 user-select: none
这两个 CSS 属性常被误用来“禁用”下拉框，但它们只是视觉/交互层的障眼法，问题很多：
-
pointer-events: none会让整个元素（包括子<option></option>）失去鼠标响应，但键盘仍可聚焦、切换、回车确认——禁用不彻底 -
user-select: none对<select></select>完全无效，它只作用于可选中文本，而下拉框本身不产生文本选择行为 - 两者都不影响表单提交逻辑，用户仍可通过 JS 修改
value并提交，后端无法区分是否“被禁用” - 缺乏语义，无障碍工具无法识别这是禁用状态，违反 WCAG 基本要求
真正需要禁用，就老实用 disabled；需要条件性锁定，优先走 JS 控制 + ARIA 声明；靠 CSS 掩耳盗铃，后期维护和兼容性都会出问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
