readonly使元素内容不可编辑但可聚焦、提交和脚本读写，仅对text类input和textarea有效；disabled则完全禁用交互且不提交数据，适用于所有表单控件。
只读属性 readonly 的实际表现和适用场景
readonly 让用户不能编辑内容，但元素仍可聚焦、可提交、可被 JavaScript 读取或修改。它只对 <input>（text、search、tel、url、email、number）、<textarea></textarea> 有效，对 <select></select>、<button></button>、<checkbox></checkbox> 等无效。
常见错误是给 <select></select> 加 readonly——浏览器会忽略，必须换思路。
- 适合展示“用户可看到、可复制、可提交”的静态值，比如订单编号、生成的 token
- 配合 CSS（如
background-color: #f5f5f5）能增强视觉提示，但别依赖样式代替语义 - 若用 JavaScript 动态设为只读：
inputElement.readOnly = true（注意大小写是readOnly，不是readonly）
禁用属性 disabled 的行为边界
disabled 彻底禁用交互：不可聚焦、不可点击、不可编辑，且该字段**不会随表单一起提交**。它适用于所有表单控件：<input>、<select></select>、<textarea></textarea>、<button></button>、<fieldset></fieldset>。
典型误用是以为 disabled 只是“灰掉”，却忽略了它导致数据丢失——后端收不到这个字段。
- 适合临时屏蔽整个控件组（比如支付方式未选时禁用银行卡号输入框）
-
<fieldset disabled></fieldset>可批量禁用内部所有控件，比逐个加更可靠 - JavaScript 中设为禁用：
element.disabled = true；注意它返回布尔值，赋值时别写成element.setAttribute('disabled', 'disabled')——虽生效，但移除时需用removeAttribute('disabled')，不如直接操作属性干净
readonly 和 disabled 混用或切换的坑
两者不能共存于同一元素——disabled 优先级更高，一旦存在，readonly 完全失效。但现实中常有“初始只读，条件满足后启用”的需求，这时必须动态切换，而非叠加。
容易出错的是状态同步问题：比如用 JS 切换 readonly 后忘了更新 UI 样式，或切换 disabled 后没重置焦点逻辑，导致键盘 Tab 跳过本该可用的字段。
- 切换前检查当前状态：
if (!input.disabled) input.readOnly = false，避免重复设置 - 禁用后若需保留值并提交，改用
readonly+ 隐藏<input type="hidden">补充提交值 - 用
getComputedStyle(input).opacity或 class 判断视觉状态不可靠，应以input.readOnly或input.disabled属性为准
无障碍与真实用户场景中的取舍
屏幕阅读器对 readonly 和 disabled 的播报不同：readonly 通常读作“只读”，disabled 读作“已禁用”。这意味着，如果用户需要感知字段存在但不可改，readonly 更友好；如果字段根本不可用（如未登录时的“编辑资料”按钮），disabled 更准确。
另一个常被忽略的点：移动端 Safari 对 readonly 的 <input type="date"> 仍会唤起键盘，而 disabled 则完全不响应触摸——这种差异在表单兼容性测试里必须实机验证。
真正复杂的不是怎么写，而是想清楚：这个字段要不要进提交数据？用户是否需要复制内容？是否要参与表单校验？这三个问题的答案，基本就锁定了该用哪个属性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
