真正让表单元素不可用必须使用disabled属性，它使控件无法聚焦、不触发事件、不提交值；CSS的pointer-events或opacity仅视觉禁用，无法阻止Tab聚焦和表单提交。
怎么让表单元素真正不可用（不只是视觉灰掉）
只加 disabled 属性，才是让浏览器彻底忽略该控件交互、不提交值、不触发焦点和事件的唯一可靠方式。CSS 的 pointer-events: none 或 opacity: 0.5 都只是障眼法，用户仍可能用 Tab 键聚焦、回车提交，后端照样收得到值。
实操建议：
-
disabled是布尔属性，写<input disabled>或<input disabled="disabled">效果一样，推荐前者更简洁 - 动态禁用必须用 JS 操作
.disabled属性，不是.setAttribute('disabled', '')—— 后者在某些旧版 IE 下可能不生效 - 禁用后，
input、select、textarea、button、optgroup都会跳过表单序列化（FormData或form.submit()）
disabled 和 readonly 的核心区别在哪
两者都限制输入，但语义和行为完全不同：readonly 只禁编辑，不限制聚焦、不阻止表单提交；disabled 连聚焦都不允许，且值一定不会被提交。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 用
readonly想防止用户改手机号，结果用户 Tab 进去、复制粘贴绕过 —— 这时候该用disabled - 给
select加readonly完全无效（HTML 规范不支持），只能用disabled - 禁用
checkbox或radio后，其checked状态依然可读可写，但勾选动作被拦截，提交时也不会包含该字段
JS 动态控制 disabled 状态要注意什么
直接操作 DOM 元素的 .disabled 属性最稳妥，但有三个容易被忽略的坑：
- 初始渲染时用了
disabled属性，后续 JS 改成false，必须显式赋值：el.disabled = false，不能只删属性（el.removeAttribute('disabled')在部分浏览器下不重绘状态） - React/Vue 等框架中，别混用
disabled={bool}和手动 DOM 操作，状态不同步会导致 UI 和实际行为不一致 - 禁用按钮后，如果还绑了
click事件监听器，它依然会触发 ——disabled不阻止事件冒泡或监听，只是不让用户触发原生交互
disabled 元素在 Accessibility 和表单验证中的表现
屏幕阅读器会播报 “dimmed” 或 “unavailable”，这是好事；但如果你禁用了一个必填字段（比如依赖 JS 计算后才启用的 input），而没同步更新 required 属性，就会导致 HTML5 表单验证失败或逻辑错乱。
使用场景提醒：
- 禁用
submit按钮防重复提交时，记得同时移除required校验依赖，或用 JS 主动调用checkValidity()控制时机 -
fieldset上设disabled，会递归禁用所有子表单控件 —— 这比逐个加更高效，但注意它不影响legend文本的可访问性 - Chrome 115+ 开始，
disabled元素上的:focus-visible伪类不再匹配，老项目若依赖此做样式调试，得换思路
disabled 不是 CSS 类，也不是临时遮罩，它是表单控件的底层状态开关。一旦设错位置或时机，后端收不到值、用户卡在流程里、无障碍工具误报，问题往往藏得深，修起来反而花更久。
