后端收不到字段大概率是误用disabled而非readonly；disabled元素提交时被浏览器完全过滤，readonly值照常提交；readonly仅对text、password、email、textarea生效，select等需用disabled或JS模拟。
后端收不到字段？先查是不是用了disabled而不是readonly
表单提交后服务端拿不到某个字段，八成是前端误用了disabled。浏览器在构造FormData、执行form.serialize()或原生submit()时，会直接过滤掉所有disabled元素的name和value；而readonly元素的值照常出现在请求体中。request.getParameter("id")能取到，说明用了readonly；取不到，大概率是disabled写错了。
哪些元素支持readonly，哪些只能用disabled
readonly不是通用锁，它只作用于可编辑文本类控件：<input type="text">、<input type="password">、<input type="email">、<textarea>。以下写法完全无效，浏览器直接忽略：
<select readonly><input type="checkbox" readonly><button readonly>
遇到<select>只读需求，要么换成<input type="text" readonly>模拟显示，要么用 JS 禁用每个<option disabled>；checkbox/radio需保留选中态但禁交互，得用disabled + 同名<input type="hidden">补值。
JS动态控制时容易出错的点
脚本切换状态比静态写 HTML 更容易翻车，尤其跨浏览器兼容性：
立即学习“前端免费学习笔记（深入）”；
- 设
disabled：直接写el.disabled = true或el.disabled = false，安全可靠 - 设
readonly：老版 Safari 对el.readOnly = false响应慢；稳妥做法是禁用时el.setAttribute('readonly', '')，启用时el.removeAttribute('readonly') - 别同时写
readonly和disabled：后者优先级更高，readonly形同虚设，还掩盖真实逻辑 - 判断状态别用
getAttribute("readonly")（返回null或字符串），应始终用el.readOnly（注意大小写）布尔值
视觉和可访问性差异不能靠默认样式糊弄
disabled元素自带灰阶、cursor: not-allowed、自动加aria-disabled="true"，屏幕阅读器会播报“已禁用”；readonly外观和普通输入框一模一样，用户可能误点去改——你得自己加 CSS，比如background: #eee; color: #666;，否则它看起来就像个能编辑的框。
更关键的是，readonly仍可聚焦、可选中、可复制，这对展示订单号、API Key、计算结果等场景是刚需；而disabled按钮连onclick都不会触发，哪怕绑了事件也白搭。真正容易被忽略的，是<fieldset disabled>能批量禁用内部所有子控件，包括<select>和<button>，且语义清晰、兼容。
