disabled是布尔属性，存在即生效，禁用后控件置灰、无法聚焦且值不提交；禁用fieldset可批量控制子元素；readonly不可替代disabled，因它允许聚焦和提交值。
怎么用 disabled 禁用单个表单控件
直接在 <input>、<select></select>、<textarea></textarea> 或 <button></button> 标签上加 disabled 属性就行，浏览器会自动置灰、阻止聚焦和提交值。
常见错误现象：加了 disabled="false" 以为能“取消禁用”——没用，disabled 是布尔属性，只要存在就生效，值是什么都不影响。
-
disabled不需要赋值，写成<input disabled>或<input disabled>都行 - 禁用后，该字段的值不会随表单一起提交（后端收不到）
- 不能用 CSS 的
pointer-events: none替代，它不阻止键盘聚焦，也不影响表单提交行为 - 如果要用 JS 动态控制，推荐
element.disabled = true或false，别用setAttribute
禁用整个 <fieldset></fieldset> 是最省事的批量方案
想一次性禁用一组控件（比如注册表单里的“企业信息”区域），把它们包进 <fieldset></fieldset>，再给 <fieldset></fieldset> 加 disabled，里面所有可交互子元素都会被连锁禁用。
使用场景：表单分步骤、条件显隐区块、权限控制下的整块功能隔离。
立即学习“前端免费学习笔记（深入）”；
- 注意：只有
<fieldset></fieldset>的直属子元素才受控；嵌套一层<div> 就失效 <li> <code><legend></legend>不会被禁用，文字仍可读，但点击无效 - 部分老版本 IE 对
<fieldset disabled></fieldset>支持不稳定，必要时 JS 补充校验 - 禁用后，内部
<input>的值依然不会提交，和单个disabled行为一致 -
readonly对<input type="radio">、<input type="checkbox">、<select></select>无效 -
disabled会阻止focus事件，readonly不会——这对可访问性（如屏幕阅读器）有实际影响 - 两者不能共存：
disabled优先级更高，加了disabled后readonly被忽略 - 禁用后，元素仍保留在 DOM 中，
tabindex失效，按 Tab 键会跳过它 - 如果禁用的是当前聚焦元素，焦点不会自动移走，可能造成键盘操作“卡住”，建议手动
focus()到下一个可用元素 - Vue/React 等框架里，别只改 DOM 属性，要同步更新响应式数据，否则下次 re-render 可能覆盖你的禁用状态
- 服务端永远别信任前端禁用——它只是体验层限制，绕过太容易，权限和数据校验必须在后端做
为什么 readonly 不是 disabled 的替代品
readonly 只对 <input type="text">、<textarea></textarea> 有效，且关键区别在于：值照常提交，用户只能看不能改，但能聚焦、能选中、能复制。
容易踩的坑：把 readonly 当作“视觉禁用”，结果后端意外收到脏数据；或者误用于 <select></select> 或 <checkbox></checkbox>，发现根本不起作用。
JS 动态禁用时要注意表单验证和焦点管理
用 JS 设置 disabled = true 后，浏览器会跳过对该元素的原生 required 校验，但如果你之前手动触发过 checkValidity()，状态可能残留。
性能影响小，但兼容性和副作用容易被忽略：
