:read-only 和 :read-write 伪类依据元素原生 readonly 属性或 contenteditable 状态自动匹配样式，不响应 JS 逻辑禁用；仅支持 （非 hidden）、 和 contenteditable 元素，且需正确使用布尔属性写法。
怎么用 :read-only 和 :read-write 给输入框加不同样式
这两个伪类能直接区分表单项是否可编辑，不用 JS 监听状态或手动加 class。关键在于：浏览器只根据元素的 readonly 属性（或 disabled 状态）自动匹配，不看 JavaScript 是否禁用了输入逻辑。
常见错误是以为给 <input> 加了 oninput="return false" 或绑了 preventDefault 就算“只读”——不行，伪类完全不认这些，只看原生属性。
-
:read-only匹配带readonly属性的<input>、<textarea></textarea>，以及没有contenteditable或设为false的元素 -
:read-write匹配没设readonly、也没被disabled的可编辑表单控件，以及contenteditable="true"元素 -
disabled元素既不匹配:read-only也不匹配:read-write，它走自己的:disabled逻辑
:read-only 不生效？检查这三处硬性条件
伪类失效最常因为 HTML 属性写法不对、元素类型不支持，或被更高优先级样式覆盖。
- 必须用布尔属性写法：
<input readonly>，不能写readonly="false"或readonly=""（空字符串也表示 true） -
<select></select>和<button></button>不支持:read-only，哪怕加了readonly属性也无效；只有<input>（除type="hidden"）、<textarea></textarea>、contenteditable元素可用 - 如果用了
!important覆盖了伪类样式，或者父元素有pointer-events: none，视觉上像“没生效”，其实是交互被拦了
和 :disabled 混用时的样式优先级陷阱
:disabled 的权重天然高于 :read-only，哪怕你把 :read-only 写在后面，只要元素同时满足两个条件（比如既有 readonly 又有 disabled），:disabled 样式一定胜出。
立即学习“前端免费学习笔记（深入）”；
但现实中，disabled 和 readonly 语义完全不同：disabled 字段不提交、不可聚焦；readonly 字段会提交、能聚焦、只是不能改。所以别让两者共存——要么用 readonly 做“展示+可复制”，要么用 disabled 做“彻底锁定”。
- 想让只读输入框看起来灰但还能选中复制？用
:read-only { background: #f5f5f5; color: #666; } - 想让禁用按钮不可点且变灰？必须用
:disabled，:read-only对<button></button>完全无效 - Chrome 和 Safari 对
contenteditable元素的:read-write支持较稳；Firefox 旧版本可能漏掉某些情况
为什么不要用 JS 动态切换 readonly 属性来触发样式变化
虽然 JS 改 element.readonly = true 确实会触发 :read-only 生效，但容易踩两个坑：
- React/Vue 等框架里直接操作 DOM 属性，可能绕过响应式系统，导致视图与状态不一致；更稳妥的是用受控组件 + 条件 class
- 批量操作多个输入框时，频繁设/删
readonly属性会触发重排，尤其在表格或列表中滚动时卡顿明显 - 真正需要动态只读逻辑的场景（比如根据权限开关编辑），建议用 class 控制（如
.is-readonly），再用 CSS 规则模拟行为：.is-readonly input { pointer-events: none; opacity: 0.7; }
伪类适合静态、语义明确的只读状态；动态逻辑交给 class + JS 更可控。
