直接加disabled属性是唯一真正禁用表单控件的方式，仅对input、textarea、select、option、optgroup、button、fieldset等原生表单控件生效；div、span、label、p等无效，且服务端必须校验。
直接加 disabled 属性是唯一能真正禁用表单控件的方式——它让元素无法聚焦、不响应点击/回车、不触发 input 或 change 事件，且值绝不会出现在 FormData 或表单提交中。
哪些元素加 disabled 才真正生效
只对原生可交互表单控件有效：input（含 type="text"、"checkbox"、"radio"、"submit" 等）、textarea、select、option、optgroup、button、fieldset。给 div、span、label、p 加该属性完全无效，浏览器直接忽略。
常见错误现象：
-
<label disabled><input></label>——label不响应disabled，里面input依然可操作 -
<input disabled>—— 只要属性名存在就禁用，值是什么都不影响 - 用
readonly替代：它允许聚焦、允许复制、值照常提交，且对select、checkbox无效
JS 动态控制必须用 .disabled = boolean
别用 setAttribute('disabled', '') 或 removeAttribute('disabled')。前者语义不严谨，后者在某些场景下不触发重绘，UI 看似没变。
正确做法是直接操作 DOM 属性：
-
el.disabled = true—— 禁用，稳定、可读、跨浏览器一致 -
el.disabled = false—— 启用，注意：仅设为false才有效，不能只删属性 - 检查状态应写
if (el.disabled)，而非el.hasAttribute('disabled')（可能滞后）
在 Vue/React 中，仅改 DOM 的 .disabled 不同步响应式状态，下次 re-render 会覆盖；必须同时更新 data 或 state。
用 fieldset 批量禁用时的继承与失效点
<fieldset disabled></fieldset> 是最简洁的批量方案，浏览器会递归禁用所有子表单控件（包括嵌套的 fieldset），但以下情况会导致失效或异常：
- 子控件显式写了
disabled="false"或disabled=""—— 多数现代浏览器仍以子元素显式声明为准，父级禁用被覆盖 -
label的for指向了fieldset外的控件 —— 点击label会绕过禁用逻辑 - 用了 Vue/React 封装的自定义组件，或 Shadow DOM —— 原生继承链断裂，禁用无法穿透
-
fieldset设置了display: flex或grid—— Safari 和 IE11 下部分子控件可能失去禁用样式（视觉灰显但焦点可入）
legend 文本不受影响，仍可聚焦、可读取；如需一并“屏蔽”，得额外加 CSS 或 JS 控制。
禁用后容易被忽略的副作用
禁用不是静默结束，而是一连串隐性影响：
- 焦点不会自动移走，用户按 Tab 可能卡在已禁用元素上；应手动调
nextElement.focus() - 若该控件之前有
required，禁用后 HTML5 验证跳过，但checkValidity()缓存状态可能残留；建议禁用后顺手调一次reportValidity() -
disabled按钮上仍可绑定并触发click事件监听器（它只拦截原生交互，不阻止事件冒泡） - 服务端永远不能信任前端的
disabled状态——绕过只需删掉属性或直接发 POST 请求；权限和字段校验必须落在后端
如果业务需要“显示但不可改”又得提交值，别硬套 disabled：改用 readonly（注意 select/checkbox/radio 不支持），或配合 hidden 输入框传值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
