disabled使控件变灰、不可聚焦且不提交值；readonly保持外观可聚焦，支持复制但禁止编辑，仅适用于文本类输入且提交时保留值。
readonly 和 disabled 都能阻止用户编辑输入内容，但它们的视觉表现、交互能力、提交行为完全不同——选错一个，后端收不到值、用户无法复制关键信息、甚至按钮失效都可能发生。
disabled 输入框会变灰且完全不可聚焦
浏览器对 disabled 有强默认样式：背景色变浅、文字颜色变灰、边框弱化，且元素无法获得焦点（tab 键跳过、鼠标点击无响应）。这代表“该控件当前不存在于可用界面中”。
- 即使你用 CSS 强行覆盖灰色（比如加
background-color: white），它依然不能被聚焦、不能被选中、不能触发focus或click事件 -
disabled对所有表单元素都生效：<select>、<button>、<checkbox>、<radio>全部适用 - JavaScript 中读取
element.disabled返回布尔值；设为true后，其value不会出现在FormData或传统表单提交中
readonly 输入框外观不变但禁止编辑
readonly 不改变默认样式，输入框看起来和普通可编辑状态一模一样，只是用户无法修改内容。它保留了基本交互能力，这是关键差异。
- 用户仍可点击、聚焦、双击选中文本、按
Ctrl+C复制——这对展示订单号、API Key、计算结果等场景极其重要 - 仅对
<input type="text">、<input type="password">、<textarea>有效；对<select>、<button>等无效（设了也不起作用） - 表单提交时，它的
value会被正常包含；服务端可通过request.getParameter("xxx")或等价方式拿到值 - JS 可随时修改其
value（比如动态填入时间戳），不影响 readonly 状态
同时设置 readonly 和 disabled 会发生什么
如果一个 <input> 同时写了 readonly 和 disabled，disabled 优先级更高——它会立即接管控制权，表现为变灰 + 不可聚焦 + 值不提交。此时 readonly 形同虚设。
- 这种写法常见于旧项目或 JS 动态切换逻辑出错时，容易误以为“双重保险”，实际是冗余且可能掩盖问题
- 不要依赖它做兼容兜底；应明确业务意图：是“不让用户改但要传值”（用
readonly），还是“彻底下线该字段”（用disabled） - 若需 JS 控制开关，统一用
element.disabled = true/false，避免混用两种属性
容易被忽略的关键点
很多人只关注“能不能改”，却漏掉三个实际影响交付的细节：
-
disabled的<button>点击事件根本不会触发，哪怕你绑了onclick—— 它不是“禁用点击”，而是“移除交互能力” -
readonly的<textarea>在移动端 Safari 上，长按仍可唤出“选择全部/复制”菜单，但部分 Android WebView 可能限制该行为 - 用 JS 动态设置
disabled后，若后续又通过 JS 改回false，必须确保 DOM 已就绪；否则在 React/Vue 等框架中可能因异步渲染导致状态不同步
