:read-only仅匹配具有readonly属性的可编辑表单元素；它不响应contenteditable或disabled，且在shadow dom中需显式穿透。
怎么判断一个元素真正触发 :read-only？
浏览器只认 DOM 属性 readonly（布尔属性），不看 contenteditable="false" 或 disabled，也不管 JS 是否锁了输入逻辑。哪怕你用 input.setAttribute('readonly', 'readonly')，只要属性存在，:read-only 就生效；删掉就失效。
-
textarea、input[type="text"]、input[type="email"]等可编辑表单控件才支持该伪类，div或span加readonly属性无效 -
contenteditable="true"的元素即使设了readonly，也不会匹配:read-only—— 它走的是[contenteditable="false"]的 CSS 逻辑 - 注意 Safari 15.4 之前对
:read-only在input[type="number"]上的支持有 bug，会漏匹配
:read-write 和 input:not([readonly]) 有什么区别？
表面看都“不是只读”，但语义和覆盖范围完全不同：:read-write 是 UA 判定的“当前可编辑状态”，而 input:not([readonly]) 只是检查属性是否存在。
-
:read-write对没有readonly属性但被 JS 禁用（如el.disabled = true）的元素**不生效** —— 它不等于“可写”，而是“未被声明为只读且未被禁用” -
input:not([readonly])会匹配所有没写readonly的input，哪怕它被disabled或contenteditable="false"控制着 - 想样式区分“真正能输内容”的输入框？优先用
:read-write；只想按 HTML 属性筛，用属性选择器更稳
为什么给 textarea 加 :read-only 样式没反应？
常见原因是用了内联样式或 !important 覆盖了伪类规则，或者父级设置了 pointer-events: none 导致鼠标事件被拦截，视觉上像“没生效”，其实是交互被掐断了。
- 确保 CSS 优先级足够：伪类选择器权重是 0,1,0，比标签选择器高，但低于 class 或 id；别让
textarea { color: #333; }直接盖掉textarea:read-only { color: #999; } -
:read-only不影响tabindex或焦点行为，如果元素无法获得焦点，不是伪类问题，是tabindex="-1"或aria-hidden干的 - Chrome 115+ 开始，
:read-only在 Shadow DOM 内部默认不穿透，需显式加::slotted(input:read-only)或用:host(:has(input:read-only))
兼容性与渐进增强怎么兜底？
IE 完全不支持这两个伪类，Edge 12–18 支持但有渲染延迟；现代项目若需兼容到 iOS 14.5 以下，得靠 JS 检测 + class 注入。
立即学习“前端免费学习笔记（深入）”；
- 简单兜底：用
input[readonly]和input:not([readonly])写两套规则，再用@supports selector(:read-only)包一层覆盖，老浏览器自动降级 - JS 检测示例：
if (CSS.supports('selector(:read-only)')) { /* 加载伪类样式 */ } else { document.querySelectorAll('input[readonly]').forEach(el => el.classList.add('is-readonly')) } - 别依赖
:read-only做权限控制 —— 它纯属表现层，用户删掉readonly属性就能绕过，后端仍需校验
伪类本身不改变可编辑性，只响应状态；真正容易被忽略的是：它的匹配结果可能滞后于 JS 修改属性后的重排，尤其在快速 toggle readonly 时，建议加 el.offsetHeight 强制同步或用 requestAnimationFrame 延迟样式应用。
