readonly仅对input(text类)和textarea有效,值可提交、支持聚焦复制;select、checkbox、button等不支持,contenteditable元素须用contenteditable="false"。

只读不是禁用,别直接套 disabled —— 90% 的表单提交丢失问题都出在这儿。
哪些元素能用 readonly?
它只对真正「可编辑的文本输入控件」生效:input(type="text"、"email"、"number"、"date" 等)和 textarea。其他统统无效:
-
select:设了readonly浏览器直接忽略,Chrome/Firefox/Safari 行为不一致,别依赖 -
input[type="checkbox"]或[type="radio"]:属性存在也无反应,勾选照常 -
div、span、button:加了等于没加,既不阻止交互,也不改变语义 -
contenteditable元素(如div[contenteditable="true"]):必须用contenteditable="false",readonly完全不认
readonly 和 disabled 到底怎么选?
关键看业务需求是否需要「值参与提交」:
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML,替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度,HTML 能同时承载排版、表格、SVG 等。
- 要提交值(比如用户 ID、预填邮箱、系统生成的时间戳)→ 必须用
readonly - 不提交值,且希望视觉弱化、彻底禁用所有交互(比如灰掉的计算结果)→ 用
disabled - 误用
disabled导致后端收不到字段,是最常见的线上问题之一 -
readonly元素仍可聚焦、可复制、可被Tab切入;disabled则完全脱离焦点流,屏幕阅读器也可能跳过
JS 动态控制 readonly 的正确写法
别用 setAttribute 或 removeAttribute,部分浏览器(尤其是旧版 Safari)不触发状态更新:
- 设只读:
inputEl.readOnly = true(注意 JS 属性名是readOnly,首字母大写) - 取消只读:
inputEl.readOnly = false - 检查状态:
if (inputEl.readOnly),不是inputEl.hasAttribute('readonly') - 错误示范:
inputEl.setAttribute('readonly', 'false')—— 只要属性存在就只读,值真假无关
样式与无障碍不能漏
纯 HTML 属性不提供视觉反馈,用户可能误以为还能编辑:
- 用 CSS
:read-only伪类统一加样式:input:read-only { background: #f9f9f9; cursor: not-allowed; } - 对不支持
:read-only的老浏览器(如 IE),需手动加 class 做降级 - 必须显式声明
aria-readonly="true",否则读屏软件无法准确播报状态 - 如果用了
contenteditable="false",还得配tabindex="-1"防止键盘聚焦,再监听keydown+beforeinput防绕过
最常被忽略的是:只读 ≠ 安全。前端限制只是体验层,服务端必须校验字段值是否被篡改,尤其当该字段影响权限或金额时。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










