:read-write仅匹配实际可编辑的原生表单控件（如text、email类input和textarea），不匹配contenteditable元素或带readonly/disabled属性的控件，加粗边框应优先用:focus结合属性选择器实现。
如何用 :read-write 选中可编辑元素并加粗边框
直接说结论：:read-write 只匹配「当前处于可写状态」的表单控件，不是所有 contenteditable 元素都算数，也不是靠 readonly 属性值决定——它看的是**实际可编辑能力**。
常见错误是给 div[contenteditable="true"] 直接套 :read-write 样式，结果没反应。因为浏览器默认不把 contenteditable 元素纳入 :read-write 的匹配范围（除非它被显式聚焦且未被禁用）。
-
:read-write原生支持的元素只有：input（非type="radio"/"checkbox"/"file"等只读类型）、textarea、select -
contenteditable元素需配合:focus才能触发活跃态样式，例如：[contenteditable]:focus { border: 2px solid #007bff; } - 如果
input带了readonly属性，即使没设disabled，它也不匹配:read-write—— 因为此时不可写
:read-write 和 :read-only 是互斥但不覆盖全部状态
别以为加了 :read-write 就能覆盖所有“可编辑”场景。这两个伪类只处理表单控件的**内在可写性**，和 JS 动态控制无关。比如你用 JS 把 input 的 readOnly 属性设为 false，样式不会自动更新，得靠 class 切换或重排版触发。
-
:read-write匹配：未设readonly、未设disabled、且类型本身支持输入（如text、email）的input -
:read-only匹配：显式带readonly属性，或type="range"这类天生不可文本输入的控件（部分浏览器行为不一致） - 既不匹配
:read-write也不匹配:read-only的情况很常见：比如input[type="hidden"]、button、自定义组件——它们压根不在这个伪类的作用域里
加深边框这类活跃态样式，优先用 :focus-within 或 class 控制
想让可编辑区域在获得焦点时加粗边框，:read-write:focus 看似合理，但兼容性和语义都有问题：Safari 对 :read-write 支持较晚（iOS 15.4+），且 :focus 本身已足够表达“当前活跃”这一意图。
立即学习“前端免费学习笔记（深入）”；
- 更稳妥的做法是：
input:not([readonly]):not([disabled]):focus, textarea:not([readonly]):not([disabled]):focus { border-width: 2px; } - 对
contenteditable元素，直接用：[contenteditable="true"]:focus { border: 2px solid #007bff; }，再配合outline: none避免双焦点框 - 如果需要区分“可编辑但未聚焦”和“已聚焦”，纯 CSS 没法靠
:read-write实现——它不响应鼠标悬停或初始状态，只响应可写性+渲染时机
容易被忽略的边界：表单控件的 type 决定是否进 :read-write
很多人以为只要没加 disabled 就算可写，其实 type 才是关键开关。比如 input[type="number"] 在某些浏览器中，当输入非法字符（如字母）时会临时变成只读态，此时 :read-write 样式会消失——这不是 bug，是浏览器按规范做的状态同步。
- 明确不匹配
:read-write的类型：hidden、submit、button、image、reset、file（哪怕没设readonly） -
input[type="date"]等日期控件，在未打开选择器时仍算:read-write；但一旦弹出原生 picker，焦点可能脱离 input，导致样式回退 - 服务端渲染或 SSR 场景下，若初始 HTML 中
input已带value但无readonly，它仍匹配:read-write——这点常被前端忽略，误以为“有值就该变只读”
真正要控制“可编辑性视觉反馈”的地方，往往不在伪类选择器本身，而在你是否清楚每个控件的 type 行为、是否混用了 readonly 和 disabled、以及有没有把 contenteditable 当成表单控件来对待。
