直接添加 disabled 属性可真正禁用表单控件，使其不可交互、不提交、视觉置灰；它是布尔属性，存在即生效，JavaScript 应用 el.disabled = true/false 控制，框架中须绑定布尔值而非字符串。
怎么让 <input>、<select>、<textarea> 真正不可用
加 disabled 属性是最直接有效的方式，浏览器会禁用交互、忽略提交、视觉置灰。注意它和 readonly 有本质区别：readonly 只禁输入但保留提交和焦点，disabled 则完全从表单数据流中剔除该字段。
常见错误是只写 disabled="false" 或 disabled="0" —— 这些在 HTML 中全都是“真值”，等价于 disabled，组件照样被禁用。HTML 的布尔属性只要存在就生效，不看值。
-
disabled是布尔属性，写成<input disabled>或<input disabled="">效果一致 - JavaScript 动态控制时，用
el.disabled = true/false，不要用setAttribute('disabled', 'false') - 被
disabled的元素不会触发focus、click（除非用 JS 强行 focus，但用户仍无法操作）
为什么 fieldset 加 disabled 能批量禁用子表单控件
<fieldset disabled> 会递归禁用其内部所有可表单控件（<input>、<select>、<textarea>、<button>、<output>），且子元素无需再单独加 disabled。这是 HTML5 原生支持的语义化批量控制方式。
但要注意：如果子元素自己显式设置了 disabled，它的状态会覆盖 fieldset 的继承；反之，若子元素没设 disabled，则完全受 fieldset 控制。
立即学习“前端免费学习笔记（深入）”；
<fieldset disabled> <legend>用户信息</legend> <input type="text" name="name"> <select name="role"><option>管理员</option></select> </fieldset>
上面两个控件都会被禁用，且提交时不会包含 name 和 role 字段。
用 CSS 模拟禁用效果不可靠，别这么干
仅靠 pointer-events: none + opacity: 0.6 不能真正停用表单组件。用户仍可通过 Tab 键聚焦、用 Enter 提交、屏幕阅读器可读、JS 仍能获取值并提交 —— 安全性和可用性全崩了。
- 服务端永远不能信任前端“视觉禁用”，必须校验字段是否应参与业务逻辑
- 辅助技术（如读屏软件）依赖
disabled属性判断控件状态，CSS 无效 - 键盘操作（Tab / Shift+Tab / Space / Enter）不受 CSS 影响，仍可能意外触发行为
React/Vue 中动态控制 disabled 的典型陷阱
框架里容易犯的错是把 disabled 当作普通 prop 绑定字符串，比如 :disabled="isDisabled ? 'disabled' : ''" —— 这会导致 Vue 把空字符串也当作属性存在，等效于禁用。React 同理，disabled={isDisabled ? "disabled" : null} 也不对，应始终用布尔值。
- Vue：写成
:disabled="isDisabled"（响应式布尔） - React：写成
disabled={isDisabled}（JSX 中布尔属性只认 true/false） - 不要用
className或style替代disabled来“看起来不可用”
最易被忽略的是：禁用状态变更后，若组件未重新渲染或 DOM 未同步，旧的 disabled 属性可能残留。检查浏览器开发者工具 Elements 面板里的实际属性是否存在，比看样式更可靠。
