readonly 仅禁用编辑但允许提交，适用于需展示且需提交的字段；disabled 则完全排除在表单提交和交互之外，适用于临时禁用场景。
readonly 属性只禁用输入，不阻止表单提交
如果你希望用户能看到字段内容、不能编辑，但提交时仍要带上这个值，readonly 是正确选择。它只让 <input>、<textarea> 失去焦点和编辑能力，不影响 form 序列化行为。
常见错误现象：disabled 误用于“只读展示”，结果后端收不到该字段——因为浏览器根本不会把 disabled 元素的值包含在提交数据中。
-
readonly适用于：身份证号预填、订单编号展示、系统生成时间等需要呈现且需提交的场景 -
disabled适用于：临时禁用按钮、条件未满足时锁定字段（如未勾选协议前禁用提交） -
readonly对<select>和<button>无效，仅对<input>（除type="hidden"）、<textarea>生效
disabled 会让字段彻底“消失”在提交数据里
disabled 不是视觉灰化那么简单——它直接让元素脱离表单控制流。即使你用 JavaScript 动态设置 disabled="false"，只要原始 HTML 里写了 disabled，某些老版本浏览器（如 IE11）可能仍忽略其值。
使用场景举例：注册页中，邮箱验证通过前，<input name="invite_code"> 被设为 disabled，此时它不会出现在 FormData 或 form.submit() 的默认提交中。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 所有
disabled元素都不会触发focus、click等交互事件 -
disabled元素的值不会被form.elements收集，也不会进入new FormData(form) - 若需“视觉禁用但逻辑参与提交”，必须用
readonly+ CSS 模拟灰化（如opacity: 0.6）
readonly 和 disabled 在 CSS 样式上表现不同
浏览器默认会给 disabled 元素加灰化样式（opacity 降低 + cursor: not-allowed），但 readonly 默认无视觉变化——它看起来完全可编辑，只是敲键盘没反应。这容易造成用户困惑。
所以实际项目中，readonly 几乎总要配 CSS：
input[readonly] {
background-color: #f5f5f5;
cursor: default;
}
-
readonly元素仍可被tab键聚焦，disabled则跳过 -
readonly支持select()方法全选文本，disabled不支持 - 移动端 Safari 对
readonly输入框有时会隐藏软键盘，但仍有聚焦反馈；disabled则完全无响应
JavaScript 修改 readonly/disabled 状态要注意时机
用 JS 切换状态时，别在 DOM 尚未加载完成时操作——比如在 <head> 里执行 document.getElementById("x").readOnly = true，很可能找不到元素。
更关键的是：不要依赖 getAttribute("readonly") 判断状态，它返回 null 或字符串 "readonly"，而实际布尔值要看 element.readOnly（注意大小写）属性。
-
element.readOnly返回布尔值：true表示只读，false表示可编辑 -
element.disabled同理，是布尔属性，不是字符串 - 动态启用
readonly字段后，记得调用element.focus()如果需要用户立刻编辑
readonly 和 disabled 的语义边界，后端收不到数据或者前端交互异常，都是第二天早上第一个报错。 
