:read-write仅匹配明确可编辑且未被readonly或disabled禁用的原生可编辑元素；div[contenteditable]虽匹配但safari支持较晚；需独立定义样式，框架中需正确绑定readonly属性以避免残留。
为什么 :read-write 在大多数输入框上不生效？
因为浏览器对 :read-write 的判定非常严格：它只匹配「明确可编辑且未被 readonly 或 disabled 禁用」的表单控件，且仅当该元素原生支持内容编辑（如 input[type="text"]、textarea）时才触发。很多开发者误以为给 input 加了 value 就算“可写”，其实只要没显式移除 readonly 属性，哪怕 DOM 上没写这个属性，JS 动态设过一次也会让 :read-write 失效。
-
input[readonly]→ 匹配:read-only，不匹配:read-write -
input（无readonly、无disabled）→ 匹配:read-write -
input[disabled]→ 既不匹配:read-write也不匹配:read-only（被完全排除在伪类作用域外） -
div[contenteditable]→ 匹配:read-write，但需注意 Safari 对它的支持较晚（iOS 16.4+ 才稳定）
:read-write 和 :read-only 的实际样式差异怎么设？
它们是互斥伪类，但不能靠“覆盖”来实现状态切换——必须分别定义，且优先级一致时后声明的规则会生效。常见错误是只写 :read-write 样式，忘了禁用状态下视觉反馈缺失。
input:read-write {
background-color: #fff;
border-color: #007bff;
}
input:read-only {
background-color: #f8f9fa;
border-color: #6c757d;
cursor: not-allowed;
}
- 不要依赖
:read-write去“撤销”:read-only的样式，两个伪类应独立完整定义 -
textarea同样适用，但需注意其默认resize行为不受伪类影响 - 若用 JS 切换
readonly属性，样式会立即响应，无需手动触发重绘
Vue/React 中动态控制 :read-write 的坑
框架绑定的 readonly 属性如果用布尔值直接插值（如 :readonly="isLocked"），当 isLocked 为 false 时，HTML 中仍可能残留 readonly="false" 字符串——这在 HTML 规范中仍是有效 readonly 属性，导致元素始终匹配 :read-only。
- Vue：用
v-bind:readonly.prop="isLocked"或条件指令v-if/v-else控制属性存在与否 - React：用
readOnly={isLocked}（注意是readOnly，首字母小写），React 会自动处理属性移除逻辑 - 检查渲染后的 DOM，确认
readonly属性是否真的不存在，而不是值为false
兼容性与替代方案提醒
:read-write 在 Chrome 47+/Firefox 45+/Safari 15.4+ 支持良好，但 Edge Legacy（≤18）完全不支持。如果你需要向下兼容到 IE 或旧版 Edge，别指望它；改用自定义 class（如 .is-editable）配合 JS 切换更可靠。
- 不要把
:read-write当作“用户正在输入”的判断依据——它只反映属性状态，和焦点、输入行为无关 - 想响应实时编辑状态，应该监听
input或change事件，而非依赖伪类 - 移动端 iOS Safari 对
contenteditable+:read-write的组合有闪烁问题，建议加transform: translateZ(0)强制硬件加速
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
