readonly属性使input不可编辑但可聚焦、选中、复制且值能提交，是需展示+提交场景的唯一合理选择；disabled则完全禁用交互且不提交值。
readonly 属性让 input 保持可提交但不可编辑
当你要让用户看到值、能选中复制、还能随表单一起发到后端时，readonly 是唯一合理选择。它不改变视觉样式（默认还是白色背景），但阻止所有输入行为。
常见错误是写成 readonly="true" 或用 .setAttribute('readonly', 'readonly') 动态控制 —— 这在旧版 Safari 上可能失效。正确做法是直接操作 DOM 属性：
-
inputEl.readOnly = true（注意大小写，是readOnly，不是readonly） - 检查状态也应写
if (inputEl.readOnly)，而不是hasAttribute - 若不想让用户聚焦该框，额外加
tabindex="-1"
disabled 属性彻底禁用控件并阻止提交
disabled 不只是“不能输”，它让元素完全退出表单交互流：无法聚焦、不能被 tab 切换、不会触发 input 或 change 事件，最关键的是——它的值根本不会出现在 FormData 或序列化结果里。
典型误用场景：用 disabled 显示用户 ID，结果后端收不到这个字段。此时应该换 readonly，或配一个同名 <input type="hidden"> 补位。
立即学习“前端免费学习笔记（深入）”；
- 写法只需
disabled（布尔属性，无需值），disabled="disabled"也合法但冗余 - 可作用于
input、textarea、select、button，甚至整个fieldset -
fieldset disabled会递归禁用内部所有子控件，包括嵌套的fieldset
为什么不能用 onfocus=this.blur() 替代 readonly
这种写法看似让输入框“点不了”，实际埋了三个坑：光标不出现、无法选中文本、屏幕阅读器可能误判为异常控件。它既没语义，也不符合无障碍标准（WCAG），更没法保证所有浏览器行为一致。
更重要的是，它绕过了 HTML 原生的表单约束机制 —— 比如你后续用 JavaScript 监听 inputEl.readOnly 状态，它永远返回 false，而真实需求可能是“根据条件切换只读/可编辑”。用原生属性才能和现代表单验证、框架响应式逻辑对齐。
select 和 textarea 不支持 readonly 的例外情况
readonly 对 <select></select> 完全无效，浏览器直接忽略；对 <textarea></textarea> 有效，但部分老版本 Android 浏览器有兼容问题。遇到下拉框只读需求，只能用 disabled + 隐藏域补值，或改用 div + CSS 模拟下拉展示（需手动维护值同步）。
另外，disabled 在 fieldset 上生效，但 readonly 不支持作用于容器级元素 —— 想批量控制一组输入框，fieldset disabled 是最干净的方案。
