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