用 readonly 还是 disabled 取决于是否需提交字段值：readonly 保留值、可聚焦、能复制；disabled 禁用交互、不提交、无法聚焦。表单丢失值常因误用 disabled。
用 readonly 还是 disabled？看场景选对属性
两者都能让文本框不能输入，但行为差异很大：readonly 保留值、可聚焦、能被表单提交；disabled 会禁用交互、跳过表单提交、默认变灰、无法获得焦点。
- 需要用户看到内容、还能复制文字（比如订单号预填）→ 用
readonly - 临时锁定整个字段且不参与提交（比如审核中禁用备注）→ 用
disabled - 用
disabled后 JS 读input.value仍有效，但提交时该字段不会出现在 FormData 或 query string 中
JS 动态设置不可编辑：别漏掉 tabindex 和样式同步
单纯设 element.readonly = true 或 element.disabled = true 不够。用户可能通过 Tab 键聚焦到只读框却无法操作，体验割裂；CSS 也没法自动响应状态变化。
- 设
readonly时建议加tabindex="-1"防止键盘聚焦（除非你明确要支持聚焦+复制） - 设
disabled时浏览器自带禁用样式，但自定义主题下常需手动补input:disabled { cursor: not-allowed; } - 用 JS 切换状态后，记得同步更新 ARIA 属性，例如
el.setAttribute('aria-readonly', 'true')
Vue/React 中绑定不可编辑状态的常见翻车点
框架里靠数据驱动 DOM，但容易忽略属性和布尔值的映射逻辑。
- Vue 模板中写
:readonly="isLocked"正确；写readonly="{{ isLocked }}"或漏掉:就会变成静态字符串，永远为真 - React 中
<input readonly>注意是readOnly（大驼峰），不是readonly，拼错直接无效 - SSR 场景下，服务端渲染时
disabled状态若和客户端不一致，可能触发 React 警告甚至 hydration error
表单提交时发现值丢了？检查 disabled 是否误用
这是最隐蔽也最高频的问题：UI 看起来锁住了，但后端收不到字段，查半天发现是用了 disabled 却没意识到它会让字段彻底退出表单序列化流程。
立即学习“前端免费学习笔记（深入）”；
- Chrome DevTools 的 Elements 面板里，右键检查 input 元素，看属性列表是否真有
disabled或readonly - 用
new FormData(formEl)在控制台打印看看字段是否在内，比猜靠谱得多 - 如果必须视觉禁用又得传值，改用
readonly+ CSS 模拟禁用样式（如background: #f5f5f5; pointer-events: none;），而不是disabled
readonly 和 disabled 的选择往往卡在「要不要参与提交」这个边界上，而这个边界经常被产品需求描述绕过去——比如“用户不能改，但得留着”这种话，得立刻追问一句：“那后端需要这个值吗？” 
