disabled 是语义锁，仅对原生表单控件生效且存在即禁用；用于 select 时整框冻结、不提交数据，与 readonly 本质不同；option 上 disabled 为弱禁用，鼠标仍可选中；JS 控制应直接操作 .disabled 属性并闭环逻辑；框架中宜过滤数据而非硬加 disabled；后端必须校验。
disabled 属性不是“开关”，而是“语义锁”——它只在原生表单控件上生效，且一旦存在就强制禁用，不管值是 true、false 还是空字符串。
给 <select> 加 disabled 是整块冻结
加在 <select> 标签上，整个下拉框变灰、无法点击、不能展开、不响应键盘（包括 Tab 跳转时跳过），且提交时该字段**完全不出现在表单数据中**。这和 readonly 有本质区别：readonly 对 <select> 无效，写了也白写。
- 适用场景：二级联动中“城市”下拉在“省份”未选时必须不可操作，但又不能从 DOM 中移除
- 副作用：如果后端依赖这个字段必传，禁用会导致缺失；需配合 hidden input 补位或服务端容错
- 样式注意：某些自定义 CSS（比如覆盖了
pointer-events或重置了opacity）可能削弱禁用视觉反馈，建议显式加select:disabled { cursor: not-allowed; }
给 <option> 加 disabled 只锁单条，但鼠标仍可点
<option disabled> 让某项变灰、键盘不可选、焦点不可入，但它**不阻止鼠标点击选中**——Chrome/Firefox 下快速点击仍可能触发选择，且部分浏览器提交时仍会带上该值。这不是 bug，是 HTML 规范允许的“弱禁用”。
- 别写
disabled="false"或disabled="0"，布尔属性只要存在即生效 - 若该选项同时带
selected，页面加载后它会显示为当前值，但用户无法手动选中；风险在于用户直接提交，后端收到空值或脏值 - 安全做法：用
<option value="" disabled selected>-- 请选择 --</option>作占位，确保初始值明确、无业务含义
JavaScript 动态控制 disabled 的三个关键点
用 JS 切换状态时，直接操作 .disabled 属性最可靠，而不是 setAttribute 或 removeAttribute。但光改属性不够，还得处理逻辑闭环。
立即学习“前端免费学习笔记（深入）”；
- 判断状态必须用
if (el.disabled)，不要用hasAttribute('disabled')——DOM 属性更新和 attribute 同步可能不同步 - 禁用某个
<option>后，如果当前selectedIndex恰好指向它，得主动切换：select.selectedIndex = 0或select.value = '' - 监听
change事件拦截非法选择比依赖disabled更稳妥，尤其对鼠标点击场景：if (select.value === 'banned-value') select.value = ''
框架里慎用原生 disabled 到 <option>
React/Vue 等框架的虚拟 DOM 渲染机制，会让硬写的 disabled 属性在 re-render 后被覆盖。比如 React 中 map 渲染选项时，若没用 key 或没同步状态，禁用标记可能瞬间消失。
- 更稳的做法：从数据源过滤掉禁用项，而不是渲染后再加
disabled - 若必须保留 DOM 位置（如动画、滚动锚点），用
key强制重建，或结合disabled+className控制样式 - 永远别省略后端校验：前端禁用只是体验层，服务端必须校验提交的
value是否在允许列表内
真正难的不是加不加 disabled，而是想清楚“禁用”到底要达成什么效果：是彻底不让用户碰，还是仅提示不可选？前者锁 <select>，后者筛数据或加交互拦截。混用或误判，八成会在移动端 Safari 或屏幕阅读器里露出破绽。
