readonly属性允许表单提交其值，disabled属性则阻止提交；前者适用于需保留值的只读展示（如用户ID），后者适用于临时禁用且不提交的控件（如未同意协议时的提交按钮）。
readonly 属性只阻止输入，不阻止表单提交
readonly 会让 <input> 或 <textarea></textarea> 内容不可编辑，但元素仍可聚焦、可选中、可复制，关键点是：它的值会随表单一起提交。常见于展示型字段（如用户 ID、订单编号）需保留但禁止修改的场景。
容易踩的坑：
-
readonly对<select></select>、<button></button>、<checkbox></checkbox>等无效 —— 浏览器直接忽略，不会产生任何行为 - 用 JavaScript 动态设置时，写法是
element.readOnly = true（注意大小写，是readOnly，不是readonly） - 如果同时设了
readonly和disabled，disabled优先级更高，readonly被覆盖
disabled 属性让控件完全失效且不参与提交
disabled 不仅禁用编辑，还导致元素无法聚焦、无法选中、无法复制，更重要的是：它的值**不会被包含在表单提交数据中**（即后端收不到该字段）。适用于临时禁用某项功能（如“同意协议”未勾选时禁用提交按钮）。
使用注意：
立即学习“前端免费学习笔记（深入）”；
-
disabled对所有表单控件都有效，包括<select></select>、<fieldset></fieldset>、<button></button>，甚至能作用于整个<fieldset></fieldset> - 被
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字段照常收录
disabled，结果发现某个“只读展示字段”在后端突然收不到值——问题往往就卡在这两个属性的提交语义差异上。 
