:read-only 和 :read-write 是css伪类，用于根据元素是否可编辑应用不同样式。1. :read-only 匹配设置了 readonly 属性或 contenteditable="false" 的元素；2. :read-write 匹配未设置 readonly 或 contenteditable="true" 的元素；3. disabled 元素不匹配 :read-only，需使用 :disabled；4. 它们可用于表单切换、验证反馈和代码展示等场景；5. 注意兼容性、contenteditable 行为差异及选择器特异性问题。正确使用这些伪类能提升用户体验并简化样式管理。
:read-only 和 :read-write 是 CSS 中非常实用的伪类，它们能让我们根据 HTML 元素是否处于可编辑状态来施加不同的样式。简单来说，就是区分那些只能看不能改的，和那些可以随意输入修改的元素，然后分别给它们“化妆”。
要使用它们，其实逻辑非常直接。当你有一个 input 字段或者 textarea，它们默认是可写的。如果你给它们加上 readonly 属性，它们就变成了只读。而 contenteditable 属性则能让任何元素变得可编辑。
:read-only 会匹配那些用户无法编辑的元素。比如一个设置了 readonly 的 input，或者一个禁用了 contenteditable 的 div。
:read-write 则相反，它匹配那些用户可以编辑的元素。这包括没有 readonly 属性的 input 或 textarea，以及设置了 contenteditable="true" 的元素。
/* 针对只读输入框的样式 */
input:read-only {
background-color: #f0f0f0;
border: 1px dashed #ccc;
cursor: not-allowed;
color: #666;
}
/* 针对可编辑输入框的样式 */
input:read-write {
background-color: #fff;
border: 1px solid #007bff;
box-shadow: 0 0 5px rgba(0, 123, 255, 0.2);
color: #333;
}
/* 针对可编辑的div */
[contenteditable="true"]:read-write {
outline: 2px solid #28a745;
padding: 8px;
min-height: 50px;
background-color: #fff;
}
/* 针对不可编辑的div (虽然通常不会直接用:read-only去匹配contenteditable="false"的div，但理论上可以) */
[contenteditable="false"]:read-only {
background-color: #f9f9f9;
border: 1px solid #eee;
padding: 8px;
color: #555;
}这里需要提一下，disabled 属性和 readonly 属性是不同的。disabled 的元素既不能编辑也不能提交，而 readonly 的元素虽然不能编辑，但其值仍会随表单提交。:read-only 伪类是针对 readonly 状态的，而非 disabled。这点有时候会让人有点混淆。
它们到底能用在哪些元素上？
这个问题问得好，因为一开始我总觉得它就只针对 input 和 textarea。但实际上，它的适用范围比我们想象的要广一些，也有些微妙的地方。
立即学习“前端免费学习笔记（深入）”；
最直观的，当然是那些标准的表单元素：
-
(除了hidden,radio,checkbox,button等本身就不可编辑的类型)
当这些元素被设置了 readonly 属性时，它们就会被 :read-only 匹配。如果没有设置 readonly，或者 readonly 属性值为 false，那它们就会被 :read-write 匹配。
但更灵活的在于 contenteditable 属性。任何 HTML 元素，只要你给它加上 contenteditable="true"，它就能变成一个富文本编辑器区域。这时候，这个元素就会被 :read-write 匹配。反之，如果 contenteditable="false" 或者没有这个属性（默认就是不可编辑的），那么它理论上就会被 :read-only 匹配。不过，对于默认不可编辑的元素，比如一个普通的 div 或者 p 标签，我们通常不会特意去用 :read-only 来匹配，因为它们本来就不可编辑，直接写样式就行了。这个伪类在 contenteditable 场景下，更多是用来区分 true 和 false 状态。
一个常见的误区是，有人可能会觉得 disabled 的元素也会被 :read-only 匹配。但事实并非如此。disabled 的元素是完全不可交互的，而 readonly 的元素虽然不能修改内容，但仍可以被选中、复制，甚至其值可以被脚本读取并随表单提交。所以，如果你想给 disabled 的元素设置样式，得用 :disabled 伪类，而不是 :read-only。这是个小细节，但在实际开发中，如果混淆了，可能会导致样式不生效。
实际开发中，这些伪类有哪些妙用？
在日常开发中，这两个伪类虽然不算是那种“炫技”的CSS属性，但用得巧了，能极大地提升用户体验和代码的可维护性。
我个人最喜欢的一个场景，就是表单的“查看模式”和“编辑模式”切换。很多后台管理系统都会有这种需求：用户点一个“编辑”按钮，表单字段就从只读状态变成可编辑。以前我们可能需要用JavaScript来回切换好几个class，或者直接操作style。现在，只要切换 readonly 属性或者 contenteditable 属性，CSS就能自动响应。
比如，一个用户资料页面：
然后CSS可以这样写：
/* 默认只读样式 */
input:read-only, textarea:read-only {
border: none;
background-color: transparent;
cursor: default;
color: #333;
}
/* 可编辑样式 */
input:read-write, textarea:read-write {
border: 1px solid #007bff;
background-color: #fff;
padding: 5px;
cursor: text;
}
/* contenteditable的只读和可写样式 */
[contenteditable="false"]:read-only {
border: 1px dashed #eee; /* 提示区域，但不可编辑 */
background-color: #f9f9f9;
padding: 5px;
}
[contenteditable="true"]:read-write {
border: 2px solid #28a745;
background-color: #fff;
padding: 4px;
min-height: 80px;
}JavaScript就只需要简单地切换属性：
function toggleEditMode() {
const userName = document.getElementById('userName');
const userBio = document.getElementById('userBio');
const userTags = document.getElementById('userTags');
if (userName.readOnly) { // 当前是只读模式，切换到编辑
userName.readOnly = false;
userBio.readOnly = false;
userTags.contentEditable = "true";
} else { // 当前是编辑模式，切换到只读
userName.readOnly = true;
userBio.readOnly = true;
userTags.contentEditable = "false";
}
}这样，所有的样式切换都由CSS自动完成，JavaScript只负责逻辑，代码会变得非常清晰。
另一个场景是表单验证时的视觉反馈。当某个字段因为某种原因（比如数据正在加载，或者等待服务器验证结果）暂时不可编辑时，我们可以通过设置 readonly 属性，然后用 :read-only 伪类给它一个灰色的背景或者虚线边框，明确告诉用户“这里现在不能动”。这比直接 disabled 要好，因为 disabled 通常意味着这个字段在当前情境下是完全无效的，而 readonly 只是暂时锁住。
还有，在一些需要展示代码或者配置文件的场景，我们可能会用 来展示内容。这时候，我们可以用 :read-only 给它一个特殊的背景色或者字体样式，让它看起来更像一个代码块，而不是一个普通的输入框。这种细微的视觉区分，能让用户更快地理解元素的用途。
使用时需要注意哪些“坑”？
虽然 :read-only 和 :read-write 用起来很方便，但实际操作中还是有些小“坑”需要我们留意，不然可能会遇到一些预期之外的问题。
首先，浏览器兼容性。虽然这两个伪类在现代浏览器中支持度已经很好了（IE9+，Edge，Firefox，Chrome，Safari都支持），但在一些老旧的浏览器或者特定版本中，可能存在兼容性问题。所以，如果你的项目需要支持非常老的浏览器，最好还是做一下渐进增强或者提供降级方案。不过，对于大多数现代Web应用来说，这已经不是一个大问题了。
其次，是关于contenteditable 的行为。当一个元素被设置为 contenteditable="true" 时，它会变成可编辑的。但如果你把它设为 contenteditable="false"，它就会变成不可编辑。这时候，这个元素会被 :read-only 匹配。但是，如果你仅仅是一个普通的 div，没有设置 contenteditable 属性，它默认就是不可编辑的，它也会被 :read-only 匹配。这听起来有点绕，但关键在于，contenteditable 属性的存在与否，以及它的值，是决定 :read-only 和 :read-write 匹配的关键。对于一个普通的、本来就不可编辑的元素，通常我们不会特意去用 :read-only 来给它加样式，因为那样写CSS可能不够直观。更多时候，我们是在动态切换 contenteditable 状态时，利用这两个伪类来做样式区分。
再来，readonly 和 disabled 的区别，前面也提过，这里再强调一下。:read-only 匹配的是 readonly 状态的元素，而不是 disabled 状态的。disabled 的元素需要使用 :disabled 伪类来匹配。这个区分在表单提交时尤为重要：readonly 的字段值会随表单提交，而 disabled 的字段值不会。所以，如果你想让用户不能编辑某个字段，但又希望它的值能被提交到后端，那么 readonly 才是你的选择，相应的样式控制就用 :read-only。
最后，是CSS选择器的特异性（Specificity）问题。如果你同时定义了针对 input 的普通样式和针对 input:read-only 的样式，那么 :read-only 的样式会因为伪类的存在而具有更高的特异性，从而覆盖普通样式。这通常是我们期望的行为，但如果你的CSS结构比较复杂，或者有其他更具体的选择器（比如ID选择器），就可能出现样式不按预期生效的情况。这时候，就需要检查选择器的特异性，确保你的 :read-only 或 :read-write 样式能够被正确应用。
总的来说，这两个伪类虽然简单，但背后涉及的HTML属性和浏览器行为还是有些细节的。理解这些，能帮助我们更高效、更准确地利用它们来优化页面
