:read-write仅匹配未禁用且非只读的原生表单元素（如text、textarea、select），不直接匹配contenteditable="true"的div等非表单元素，也不响应JS动态状态变更。
:read-write 不能直接区分“可编辑区域”和“普通文本”，它只匹配浏览器认定为「当前可编辑」的表单控件或 contenteditable 元素，且对 div、span 等非表单元素默认不生效。
哪些元素真正触发 :read-write？
浏览器只按 UA 规则判定可写性，不是看有没有 contenteditable 属性就匹配：
-
<input type="text">、<textarea>、<select>—— 没设readonly且没被disabled时才匹配 -
<div contenteditable="true">—— 多数浏览器**不直接匹配**:read-write，必须加:focus或用[contenteditable="true"]显式选择 -
<input type="hidden">、<button>、<span>—— 完全不在:read-write作用域内，样式不会生效 -
<input readonly>即使没disabled，也**不匹配**:read-write，哪怕 JS 把readOnly设为false，样式也不会自动更新
:read-write 和 input:not([readonly]) 的关键区别
表面都“不是只读”，但语义完全不同：
-
:read-write是 UA 判定的“当前可编辑状态”：它忽略 JS 动态禁用（如el.disabled = true），但会因disabled属性存在而失效 -
input:not([readonly])只检查 HTML 属性是否存在，不管是否被disabled或contenteditable="false"控制 - 想稳定控制样式，对表单控件优先用
:read-write；对动态 JS 控制场景，建议用 class 切换（如.is-editable）更可靠
常见失效原因与绕过方式
样式没反应？先排查这几点：
立即学习“前端免费学习笔记（深入）”；
- Safari ≤15.3 对
input[type="number"]:read-write有漏匹配 bug，需 fallback 用input:not([readonly])[type="number"] - 用了
!important覆盖了伪类规则，或父级设置了pointer-events: none，导致视觉上像“没生效” - 和
:disabled共存时，:disabled权重天然更高，:read-write样式会被压制 —— 别让readonly和disabled同时出现 - Shadow DOM 中需显式穿透：
::slotted(input):read-write或:host(:defined) input:read-write
真正要区分“可编辑区域”和“普通文本”，得靠组合策略：:read-write 处理原生表单，[contenteditable="true"] 处理富文本容器，再配合 :focus-within 或 class 控制活跃态。别指望一个伪类包打全部。
