后端收不到字段通常是误用disabled而非readonly；disabled元素不参与表单提交，readonly则正常提交且支持复制、聚焦等交互。
后端收不到字段？八成是把 readonly 写成了 disabled
表单提交后后端拿不到某个字段值，不是接口问题，而是浏览器压根没把它塞进请求体——disabled 元素在 new FormData(form)、form.serialize()、原生 form.submit() 中被完全过滤，连键名都不生成；readonly 则照常提交，request.getParameter("xxx") 能正常取到。
常见翻车现场：<input name="order_id" value="1001" disabled> → 后端日志查无 order_id 字段，报“缺少必传参数”。
- 字段需用户查看、复制（如 API Key、手机号），且后端必须接收 → 用
readonly - 临时锁死交互（如协议未勾选时禁用提交按钮），且不希望该值参与提交 → 用
disabled - 想让整个区块不可操作？优先用
<fieldset disabled>，比逐个加disabled更健壮、语义更清晰
readonly 不是万能锁：只对特定元素生效
readonly 只对 <input type="text">、<input type="password">、<input type="email">、<textarea> 有效；其他控件加了也白加：
-
<select readonly>→ 浏览器直接忽略，下拉框仍可点选 -
<input type="checkbox" readonly>→ 无法阻止勾选/取消 -
<button readonly>→ 完全无效，按钮照点
替代方案：
立即学习“前端免费学习笔记（深入）”；
-
<select>只读需求：改用<input type="text" readonly value="选项A">模拟，或 JS 控制每个<option disabled> -
checkbox/radio需视觉只读但保留值：用disabled+ 同名<input type="hidden">补值
JS 动态控制 readonly 和 disabled 的坑
静态写 HTML 很直观，但 JS 切换状态容易出兼容性问题：
- 设
disabled：安全写法是el.disabled = true或el.disabled = false；避免用setAttribute('disabled', '')，移除时需额外removeAttribute - 设
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 外观和普通输入框一模一样，但允许 Tab 切入、.focus() 成功、双击选中、Ctrl+A 全选、Ctrl+C 复制、监听 focus 事件。
这意味着：
- 展示需复制的字段（如调试 ID、订单号），必须用
readonly；误用disabled用户点不动、选不了、也复制不了 - 若需视觉上像“禁用”，得靠 CSS 额外加
opacity: 0.6或background: #eee -
<fieldset disabled>会自动加aria-disabled="true"，屏幕阅读器播报“已禁用”；readonly无此语义，仍按普通输入框播报
最常被忽略的点：disabled 的 <button> 点击事件根本不会触发，哪怕绑了 onclick —— 它不是“禁用点击”，而是“移除交互能力”。
