readonly控件的值会随表单提交，disabled则完全不提交；readonly可聚焦、可选中复制，disabled不可交互且样式置灰；select不支持readonly，contenteditable需JS模拟只读。
readonly 和 disabled 都让输入框不能编辑，但表单提交行为完全不同
关键判断：如果用户需要看到值、且这个值要随表单一起提交，用 readonly；如果整个字段不参与交互也不参与提交（比如临时禁用），用 disabled。
表单提交时，disabled 的值根本不会被发送
浏览器在序列化表单（比如 form.submit() 或原生提交）时，会直接忽略所有带 disabled 属性的控件。哪怕你手动设置了 value，它也不会出现在 FormData 或 URL 查询参数里。
而 readonly 控件的 value 会被正常包含——这是最常踩的坑，尤其在管理后台编辑页里，把本该提交的 ID 或状态字段误设成 disabled，导致后端收不到。
-
<input name="id" value="123" disabled>→ 提交时无id=123 -
<input name="id" value="123" readonly>→ 提交时有id=123
focus、tabindex 和样式响应也不同
disabled 元素无法获得焦点、不能被 tab 切入、:focus 伪类无效，JavaScript 调用 .focus() 也会静默失败；readonly 元素仍可 focus、可 tab 切入、支持 select()、也能触发 focus 事件。
立即学习“前端免费学习笔记（深入）”；
默认样式上，disabled 通常变灰+低透明度，readonly 外观和普通输入框一致（除非你显式重置了 :read-only 样式）。
- 想让用户能选中复制文本？必须用
readonly - 用 JS 动态控制是否可编辑？
input.disabled = true/false更直观，但记得同步处理提交逻辑 - React/Vue 中绑定
disabled时，别忘了受控组件的value依然生效，只是 UI 锁定
textarea 和 select 也遵循同一套规则，但 behavior 有细微差别
textarea 支持 readonly 和 disabled，行为与 input 一致；select 元素不支持 readonly（HTML 规范未定义），只认 disabled。若需“只读下拉”，得用其他方式模拟，比如禁用所有 option 或换成不可交互的展示文案。
另外，contenteditable 元素没有 readonly 属性，只能靠 JS 拦截 input 和 keydown 事件来模拟。
真正容易被忽略的是：某些 UI 库（比如 Ant Design 的 Input）把 readOnly 属性映射为 readonly，但文档没强调它不影响提交——结果开发在表单里用了 readOnly={true}，测试时才发现后端少收了一个字段。
