readonly属性的CSS选择器怎么写
直接用 :read-only 伪类，不是 :readonly（少个短横线会完全不生效）。这个选择器只匹配带 readonly HTML 属性的元素，和 disabled 无关，也不管表单控件是否实际不可编辑（比如 JS 动态禁用但没加属性，它就选不到）。
常见错误是写成 input[readonly] —— 这能选中，但语义弱、复用性差，且无法覆盖 textarea 或未来可能支持 readonly 的其他元素。
-
:read-only是标准伪类，浏览器兼容性好（Chrome 23+/Firefox 28+/Safari 7.1+） - 它只响应 HTML 属性存在与否，不响应 JS 修改
element.readOnly = true（除非同时显式设置element.setAttribute('readonly', '')） - 对
contenteditable元素也有效，只要它有readonly属性
只读输入框背景色设不生效的典型原因
最常踩的坑：样式被更具体的规则覆盖。比如全局写了 input { background: #fff; }，而你的 :read-only 规则没加足够权重，或者写在了前面。
另一个隐形问题：某些 UI 框架（如 Bootstrap）会给 input[readonly] 加自己的样式，甚至用 !important 锁死背景色。这时候光靠 :read-only 不够，得提高优先级。
立即学习“前端免费学习笔记（深入）”；
- 优先用
input:read-only, textarea:read-only显式限定元素类型，避免意外命中其他标签 - 必要时加
!important（别嫌它丑，框架里真需要） - 检查 computed styles，确认最终生效的是哪条规则——很多时候不是没写对，是被盖掉了
和disabled状态的视觉区分有必要吗
有必要，而且很关键。用户靠视觉判断“能不能点”，readonly 和 disabled 行为不同：readonly 值会提交、能聚焦、能复制；disabled 则完全被表单忽略。
如果两者背景色一样，用户会困惑“这框到底算不算数”。更糟的是，屏幕阅读器对两者的播报也不同，混用影响可访问性。
-
:read-only推荐用浅灰背景（如#f5f5f5）+ 正常文字色，保留可读性 -
:disabled用更深灰（如#e9ecef）+ 降低文字透明度（color: #6c757d） - 千万别用同一套
opacity: 0.6处理两者——readonly不该削弱可读性
要不要用JavaScript辅助判断状态
纯 CSS 足够应付大多数场景，但如果你的只读逻辑是动态的（比如根据权限开关 readonly），就得小心：CSS 只看属性是否存在，不感知 JS 状态。
例如，你用 inputEl.readOnly = true 却没调 inputEl.setAttribute('readonly', '')，:read-only 就不会触发。这时候要么补上 setAttribute，要么改用 class 控制样式（如 .is-readonly）。
- 服务端渲染或静态 HTML 场景，
:read-only安全可靠 - 前端强交互应用，建议统一用 class + JS 同步控制，避免属性和 DOM 状态错位
- 若坚持用属性，记得所有修改都走
setAttribute/removeAttribute，别只动 JS 属性
:read-only，而是搞清楚它到底依赖什么、谁在覆盖它、以及用户到底怎么看懂那个颜色。 
