disabled是布尔属性，存在即生效，禁用后控件置灰、无法聚焦且值不提交；禁用fieldset可批量控制子元素；readonly不可替代disabled，因它允许聚焦和提交值。

怎么用 disabled 禁用单个表单控件

直接在 、、 或 标签上加 disabled 属性就行，浏览器会自动置灰、阻止聚焦和提交值。

常见错误现象：加了 disabled="false" 以为能“取消禁用”——没用，disabled 是布尔属性，只要存在就生效，值是什么都不影响。

• disabled 不需要赋值，写成 或 都行
• 禁用后，该字段的值不会随表单一起提交（后端收不到）
• 不能用 CSS 的 pointer-events: none 替代，它不阻止键盘聚焦，也不影响表单提交行为
• 如果要用 JS 动态控制，推荐 element.disabled = true 或 false，别用 setAttribute

禁用整个

是最省事的批量方案

想一次性禁用一组控件（比如注册表单里的“企业信息”区域），把它们包进

，再给

加 disabled，里面所有可交互子元素都会被连锁禁用。

使用场景：表单分步骤、条件显隐区块、权限控制下的整块功能隔离。

• 注意：只有
  的直属子元素才受控；嵌套一层
  就失效
• 不会被禁用，文字仍可读，但点击无效
• 部分老版本 IE 对
  支持不稳定，必要时 JS 补充校验
• 禁用后，内部 的值依然不会提交，和单个 disabled 行为一致

为什么 readonly 不是 disabled 的替代品

readonly 只对 、 有效，且关键区别在于：值照常提交，用户只能看不能改，但能聚焦、能选中、能复制。


HTML Text Extract
从HTML页面（URL、文件或标准输入）中提取主体内容文本，去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。
下载

容易踩的坑：把 readonly 当作“视觉禁用”，结果后端意外收到脏数据；或者误用于 或 ，发现根本不起作用。

• readonly 对 、、 无效
• disabled 会阻止 focus 事件，readonly 不会——这对可访问性（如屏幕阅读器）有实际影响
• 两者不能共存：disabled 优先级更高，加了 disabled 后 readonly 被忽略

JS 动态禁用时要注意表单验证和焦点管理

用 JS 设置 disabled = true 后，浏览器会跳过对该元素的原生 required 校验，但如果你之前手动触发过 checkValidity()，状态可能残留。

性能影响小，但兼容性和副作用容易被忽略：

• 禁用后，元素仍保留在 DOM 中，tabindex 失效，按 Tab 键会跳过它
• 如果禁用的是当前聚焦元素，焦点不会自动移走，可能造成键盘操作“卡住”，建议手动 focus() 到下一个可用元素
• Vue/React 等框架里，别只改 DOM 属性，要同步更新响应式数据，否则下次 re-render 可能覆盖你的禁用状态
• 服务端永远别信任前端禁用——它只是体验层限制，绕过太容易，权限和数据校验必须在后端做

表单禁用不是开关一按就完事，真正麻烦的是禁用后的状态同步、焦点流断裂、以及后端对“缺失字段”的预期处理。这些地方不提前想清楚，上线后问题往往出在用户看不见的地方。