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