readonly和disabled区别详解

你是否遇到过后端收不到表单字段的诡异问题？八成是因为混淆了 `readonly` 和 `disabled`——前者让字段“只读但必传”，值照常进入请求体，支持聚焦、复制和屏幕阅读器访问；后者则直接从提交数据中剔除该字段，无论JS如何修改值都无效。更关键的是，`readonly` 仅对 `input`、`textarea`、`select`（部分浏览器）等有限元素生效，而 `button`、`div` 等不支持的元素需用文本模拟或隐藏域补值；动态控制时还要避开 `readonly` 在 Safari 的兼容陷阱，且绝不能同时设置两者（`disabled` 会完全覆盖 `readonly`）。真正棘手的 bug 往往藏在条件逻辑中：某条流程路径下 JS 静默添加了 `disabled`，测试未覆盖，上线后才暴露出“缺失必传参数”的致命错误——理解这二者的本质差异，是保障表单数据完整性的第一道防线。

后端收不到字段？八成是把 readonly 写成了 disabled。这不是样式问题，是表单数据是否进请求体的根本分水岭。

提交时值会不会发到后端

这是最致命的判断依据，直接决定用哪个属性。

• disabled 的控件：无论你用 form.serialize()、new FormData(form) 还是原生 submit，它的 name 和 value 都不会出现在请求里——浏览器直接过滤掉，JS 改了 value 也白搭
• readonly 的控件：值照常提交，request.getParameter("id") 或等价方式能拿到，适合预填 ID、订单号、计算结果等“只读但必传”场景
• 常见错误现象：<input name="user_id" value="1001" disabled> 提交后后端日志查无此字段；测试通过但上线报“缺少必传参数”，基本就是这原因

哪些元素支持 readonly

readonly 不是万能锁，它只对特定元素生效，硬加在不支持的标签上等于没写。

• 有效： <input type="text">、<input type="password">、<input type="email">、<textarea>
• 无效（浏览器直接忽略）：<select readonly>、<input type="checkbox" readonly>、、<input type="radio" readonly>
• 替代方案：<select> 只读需求，改用 <input readonly> 文本模拟；checkbox/radio 需“视觉只读但保留状态”，用 disabled + 同名 <input type="hidden"> 补值

聚焦、复制、可访问性差异

用户能不能点进去、选中、复制，不是体验优化项，而是功能刚需。

• readonly 元素仍可 focus()、Tab 切入、双击选中、Ctrl+A、Ctrl+C——展示 API Key、手机号、金额时必须用它
• disabled 元素：无法获得焦点（.focus() 静默失败）、:focus 伪类不触发、鼠标点击无响应、屏幕阅读器播报 “已禁用” 并跳过
• CSS 注意：input[readonly] 默认不灰化，建议手动加 background-color: #f5f5f5; cursor: not-allowed; 做视觉提示；而 input:disabled 浏览器自带置灰，但泛写可能破坏移动端 WebView 匹配

JS 动态控制的坑点

用脚本开关状态时，两个属性的行为不一致，容易埋下静默 bug。

• 设 disabled：安全写法是 el.disabled = true 或 el.disabled = false
• 设 readonly：老版 Safari 对 el.readOnly = false 响应迟钝，稳妥做法是 el.removeAttribute('readonly')
• 别同时写 readonly 和 disabled：disabled 优先级更高，readonly 形同虚设，不是“双重保险”，而是逻辑混淆
• 批量控制首选
  ：包裹一组控件，比逐个设 disabled 更健壮，语义更清晰，子控件显式写 disabled="false" 也无效

真正难调试的，是那些“看起来提交了、实际被浏览器过滤掉”的字段——它们往往藏在条件分支里，只在某个流程路径下被 JS 动态加上 disabled，而测试时恰好没走那条路。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~