disabled的值不会发到后端，readonly的值会正常提交；前者完全禁用交互且不参与表单数据收集，后者允许聚焦、选中、复制且保留提交能力。
表单提交时值会不会发到后端？
这是最常踩的坑，直接决定该用哪个属性。disabled 的值根本不会出现在 FormData、URL 查询参数或原生 form.submit() 请求体里；readonly 的值会正常提交。比如：
→ 后端收不到 id 字段 → 后端能收到 id=123
管理后台编辑页里误把用户 ID 设成 disabled，上线后接口报“缺少必传参数”，基本就是这个原因。
用户能不能聚焦、选中、复制内容？
readonly 允许聚焦（Tab 可切入）、双击选中、Ctrl+A 全选、Ctrl+C 复制；disabled 完全阻断这些行为——连 .focus() 调用都会静默失败。
- 展示 API Key、订单号、计算结果等需要用户复制的场景，必须用
readonly - 若用
disabled，用户点不动、选不了、也复制不了，体验直接卡死 - CSS 无法绕过
disabled的交互禁用，哪怕加了background: white，它还是不能获得焦点
哪些元素支持 readonly？哪些只认 disabled？
readonly 仅对 、、 和 生效；对 、、 等完全无效，浏览器直接忽略该属性。
disabled 则通吃所有表单控件：、、 都支持，而且 还能批量禁用内部所有子控件。
想实现“只读下拉框”？ 是无效写法，得用 JS 禁用所有 ，或换成纯文本展示。
JS 动态控制时容易出错的点
用脚本切换状态时，disabled 和 readonly 的操作逻辑不一致：
-
el.disabled = true/false是安全可靠的写法 -
el.readOnly = false在某些老版 Safari 中可能不生效，稳妥做法是el.removeAttribute('readonly') - 同时写
readonly和disabled——disabled优先级更高，readonly形同虚设，别当“双重保险”用 - React/Vue 中绑定
readOnly属性时，注意 UI 库（如 Ant Design）可能没强调它不影响提交，测试阶段才发现后端少字段
真正难处理的不是“怎么写”，而是业务意图模糊时选错语义：是“不让改但要传值”，还是“彻底下线这个字段”——一旦混淆，前端看似正常，后端却收不到关键数据。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
