input:read-write加边框常无效，因该伪类仅匹配同时满足“类型支持输入+无readonly+无disabled”的原生表单控件（如、），不匹配等非文本输入控件，且div[contenteditable="true"]在safari 15.4前及chrome/firefox中支持不稳定；推荐改用属性选择器或统一使用input:not([readonly]):not([disabled])确保一致性。
为什么直接写 input:read-write 加边框经常没反应
不是选择器写错了，而是浏览器根本没匹配上。:read-write 只认“真正可编辑且未被禁用”的原生控件：必须是 <input type="text">、<textarea></textarea> 这类支持文本输入的元素，同时满足三个条件——没设 readonly、没设 disabled、类型本身允许输入。比如 <input type="radio"> 或 <input type="hidden"> 即使没加任何属性，也完全不触发 :read-write。
div[contenteditable="true"] 用 :read-write 加边框会失效
这是最常踩的坑。虽然规范说 contenteditable 元素应响应 :read-write，但实际中：
• Safari 15.4 之前基本不识别
• Chrome/Firefox 对 div:read-write 的支持不稳定，尤其在 Shadow DOM 或动态插入后
• 更关键的是：即使匹配成功，样式也可能被父级 outline 或 border 覆盖，看不出效果
实操建议：
• 改用属性选择器：div[contenteditable="true"] 直接加边框更可靠
• 如果必须用状态区分，搭配 [contenteditable="false"] 写 fallback 样式
• 避免依赖 :read-write 控制 contenteditable 元素的视觉反馈
和 input:not([readonly]) 混用时边框错乱的根源
这两个选择器语义不同，但样式叠加后容易互相干扰：
• input:not([readonly]) 匹配所有没写 readonly 属性的 input，哪怕它已被 disabled —— 此时边框仍会显示
• input:read-write 则跳过 disabled 元素，不会加边框
结果就是：同一组表单里，有的输入框有边框、有的没有，看起来像随机失效
正确做法：
• 只用一种逻辑贯穿全站：要么全走 UA 状态（:read-write），要么全走属性存在性（input:not([readonly])）
• 若需兼容旧浏览器（如 IE），必须降级为 input:not([readonly]):not([disabled])
• 在 CSS 中显式覆盖 input:disabled 的边框，避免继承污染
移动端高 DPI 下边框变粗或发虚怎么办
这不是伪类问题，而是 1px 边框在 Retina 屏上被渲染为 2 物理像素，再叠加相邻元素的边框，视觉上就“加粗”或模糊。尤其当多个 :read-write 元素垂直排列时，上下边框紧贴，冲突更明显。
轻量级修复：
• 用 border-bottom: 1px solid rgba(0,0,0,0.1) 替代纯黑，降低对比度
• 统一用 margin-bottom 替代 border-bottom 分隔，彻底避开边框叠加
• iOS Safari 加 -webkit-transform: translateZ(0) 强制硬件加速，减少抗锯齿抖动
:read-write 是否真被浏览器判定为“可编辑”。检查 DOM 属性是否存在、是否被 disabled 掩盖、contenteditable 是否写对了值——这些比调边框颜色重要得多。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
