readonly与disabled表单属性区别详解

readonly和disabled虽同为表单控制属性，却在交互行为与提交逻辑上存在本质差异：readonly让字段不可编辑但可选中、可复制，且其值会随表单正常提交，适用于需展示并保留数据的场景（如用户ID、订单号）；而disabled则彻底禁用控件，使其无法聚焦、选择或触发事件，更重要的是其值根本不会出现在提交数据中，适合临时屏蔽功能（如协议未勾选时禁用按钮）。选错属性轻则导致后端收不到关键字段，重则引发隐蔽bug——理解二者在提交语义、JavaScript操作及浏览器兼容性上的关键区别，是写出健壮表单逻辑的第一步。

readonly 属性只阻止输入，不阻止表单提交

readonly 会让 <input> 或 <textarea> 内容不可编辑，但元素仍可聚焦、可选中、可复制，关键点是：它的值会随表单一起提交。常见于展示型字段（如用户 ID、订单编号）需保留但禁止修改的场景。

容易踩的坑：

• readonly 对 <select>、、 等无效 —— 浏览器直接忽略，不会产生任何行为
• 用 JavaScript 动态设置时，写法是 element.readOnly = true（注意大小写，是 readOnly，不是 readonly）
• 如果同时设了 readonly 和 disabled，disabled 优先级更高，readonly 被覆盖

disabled 属性让控件完全失效且不参与提交

disabled 不仅禁用编辑，还导致元素无法聚焦、无法选中、无法复制，更重要的是：它的值**不会被包含在表单提交数据中**（即后端收不到该字段）。适用于临时禁用某项功能（如“同意协议”未勾选时禁用提交按钮）。

使用注意：

• disabled 对所有表单控件都有效，包括 <select>、
  、，甚至能作用于整个
• 被 disabled 的元素不会触发 click、focus 等事件（监听也收不到）
• 样式上默认变灰、透明度降低，但可通过 CSS 的 :disabled 伪类自定义，例如 input:disabled { background: #f5f5f5; }

表单提交时它们对 name/value 的影响完全不同

这是最常被忽视的实际后果：哪怕你只是想“显示但不让改”，选错属性就会丢数据。

假设表单里有：

<input name="user_id" value="12345" readonly>
<input name="status" value="pending" disabled>

提交后，后端收到的键值对只有 user_id=12345；status 字段压根不会出现在请求体里。

所以判断依据很直接：

• 需要后端接收这个字段的值？→ 用 readonly
• 只是临时屏蔽交互，且不希望它出现在提交数据中？→ 用 disabled
• 要兼容旧浏览器（比如 IE8）？两者都支持，但 disabled 在表单级控制更稳定

JavaScript 操作时的差异与风险

用脚本切换状态时，行为不一致很容易引发 bug。

disabled 是布尔属性，设为 false 即启用：el.disabled = false；而 readonly 同样是布尔属性，但某些老版本 Safari 对 el.readOnly = false 响应迟钝，稳妥做法是显式移除属性：el.removeAttribute('readonly')。

另外要注意：

• disabled 元素的 value 属性仍可读写，但修改后不会反映在 UI 上（UI 已冻结）
• readonly 元素的 value 可以被 JS 安全修改，DOM 会同步更新显示
• 用 FormData 构造对象时，disabled 字段自动被过滤，readonly 字段照常收录

本篇关于《readonly与disabled表单属性区别详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！