:read-write仅匹配未设readonly且未被disabled、交互未被拦截的textarea；:read-only仅匹配显式声明readonly属性的input（非hidden）和textarea，二者独立触发而非互斥。
:read-write 伪类本身不用于“区分”可编辑与只读——它只匹配**当前处于可编辑状态**的元素，而 :read-only 匹配明确设了 readonly 属性的 <input>（非 type="hidden"）和 <textarea></textarea>。两者不是互斥开关，而是各自独立触发。
哪些 <textarea></textarea> 真正匹配 :read-write？
只有同时满足以下全部条件的 <textarea></textarea> 才会命中 :read-write：
- 没写
readonly属性（哪怕值是"false"或空字符串也不行） - 没加
disabled属性（disabled会直接跳过:read-write和:read-only） - 没被父级设置
pointer-events: none或tabindex="-1"干扰交互能力
例如：<textarea>默认可编辑</textarea> → 匹配；<textarea readonly></textarea> → 不匹配，走 :read-only；<textarea disabled></textarea> → 两个都不匹配，只响应 :disabled。
:read-write 和 textarea:not([readonly]) 有啥区别？
表面相似，但行为完全不同：
-
textarea:not([readonly])是纯属性筛选器：只要没写readonly就选中，哪怕它被 JS 设了el.disabled = true或父级display: none -
textarea:read-write是浏览器 UA 实时判定的“可编辑性”：它要求元素不仅没readonly，还必须未被禁用、未被交互拦截、DOM 中实际可聚焦可输入 - 常见坑：
<textarea readonly></textarea>—— 这个readonly属性存在，值为字符串"false"，但布尔属性只看是否存在，不管值，所以仍匹配:read-only，不匹配:read-write
为什么给 <textarea></textarea> 加 :read-write 样式没反应？
最常因为三件事卡住：
- 写了
readonly属性但以为设成readonly="false"就等于取消——错，只要属性名存在就生效 - 用了
!important覆盖了伪类规则，或外层容器加了opacity: 0.5导致视觉误判 - 在 SSR 或 hydration 后用 JS 动态删掉
readonly，但没触发浏览器重绘判断（尤其 Safari ≤15.3 对textarea的:read-write更新有延迟）
验证方法：打开 DevTools → Elements 面板 → 看该 <textarea></textarea> 的 Attributes 列表里是否真没有 readonly 字样，再检查 Computed 标签页里 :read-write 规则是否被其他样式覆盖。
想让只读 <textarea></textarea> 看起来像“内容展示区”，别只靠 :read-only
:read-only 只负责匹配，不控制光标或文本选择行为。实际做查看模式时，必须补足这些：
- 加
user-select: text→ 允许复制内容（否则用户点不动） - 设
cursor: default→ 避免显示 I-beam，暗示不可编辑 - 保留边框但换虚线：
border: 1px dashed #d1d5db，和:disabled的实线灰区分开 - 慎用
tabindex="-1"—— 它会让<textarea readonly></textarea>失去焦点能力，而只读字段本应可聚焦（方便复制、键盘导航）
真正难处理的是后端返回的字段没带 readonly 属性，但业务逻辑上不该编辑。这种场景不能依赖 :read-write，得靠统一 class 或数据驱动样式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
