写这个CSS进阶系列的时候后台已经收到好几条“求讲嵌套”的私信了。确实对于写惯了Sass/LESS的开发者来说原生CSS在样式组织上一直像个半成品——类名又长又重复结构层级稍微深一点选择器就写得让人头皮发麻。好在前两年CSS嵌套规则终于转正主流浏览器从2023年底开始全面支持我们终于可以在不引入任何构建工具的情况下用嵌套把样式组织得干净一点。这篇就来把嵌套规则的语法、展开原理和实际坑一次性讲透适合写过一点CSS但对嵌套还不太熟的同学也适合正在纠结要不要把项目从Sass迁回原生CSS的团队参考。1. 嵌套规则是什么为什么说它是样式组织的“结构性升级”1.1 传统CSS的重复劳动先看一个人人都有过的场景。写一个简单的卡片组件如果类名是BEM风格通常会长这样.widget { ... } .widget__header { ... } .widget__title { ... } .widget__body { ... } .widget__footer { ... }这些前缀要重复写多少遍我见过最长的一个选择器是.module__item--active .module__item-text span一个类名恨不得写五行。更麻烦的是改结构的时候改类名所有相关选择器都得跟着改漏一个就是样式错乱。传统CSS的“平铺”写法本质上是在让开发者手动维护选择器之间的“父子关系”而这个信息明明就藏在HTML结构里却要在CSS里反复手打还容易打错。嵌套规则解决的就是这个问题把选择器的父子关系在CSS语法层面直接表达出来。你缩进一层浏览器就知道这是父元素内部的子元素规则视觉上的层级关系与实际DOM结构一一对应读写都顺。1.2 原生CSS嵌套的落地时间线嵌套在预处理器里早就普及了Sass 2006年就有这个能力但原生CSS却拖了很久。原因一方面是语法设计上有争议最纠结的就是到底要不要强制写以及类型选择器怎么处理另一方面是解析器和性能的适配压力。这里简单梳理几个关键节点2023年2月W3C把CSS嵌套规范推进到候选推荐标准CR阶段语法方案基本定稿。2023年8月Firefox 117率先默认支持。2023年12月Chrome/Edge 120和Safari 17.2相继支持主流浏览器实现基本齐了。也就是说从2023年底开始你可以在生产环境里放心使用原生嵌套不再需要任何构建工具做编译。如果你还需要兼容更早的浏览器那就得借助构建工具降级后面第6节我会说具体的回退方案。1.3 嵌套能做什么不能做什么嵌套不是万能药。它能帮你整理样式、减少前缀重复、让组件结构更清晰但它不会帮你自动生成类名也不会改变CSS层叠和特异性的底层逻辑。搞清楚这点很重要——很多同学学了嵌套之后以为可以随便写结果嵌套层级过深、特异性爆炸后面覆盖样式时怀疑人生。把它理解为“组织样式的语法糖”而不是“彻底重构CSS的新语言”心态就对了。2. 嵌套规则语法拆解 符号的各种正确姿势2.1 最基础用法后代选择器与伪类嵌套语法最核心的就是符号它代表“当前父选择器”。最简单的例子.card { padding: 16px; .title { font-size: 20px; } :hover { border-color: #999; } }第一行的padding是普通声明直接写。 .title会被浏览器展开为.card .title:hover展开为.card:hover。这里有个容易被忽略的好处鼠标悬停、焦点、禁用这些状态样式现在可以紧贴着主规则写不用像以前那样在全文件里四处找“某个类名后面跟着冒号”的片段。如果你愿意也可以把状态直接挂在选择器后面比如:hover .icon这样写照样没问题。只要代表父选择器你组合出什么样的选择器都行。2.2 隐式嵌套哪些场景能省略 哪些不能这里有个让很多人迷惑的细节不是所有嵌套都必须写。规范允许“隐式嵌套”也就是把省掉浏览器会自动补上。但限制条件比较严格尤其是类型选择器的处理堪称原生嵌套的第一大坑。可以省略的情况以类选择器开头.title {}相当于 .title以ID选择器开头#header {}相当于#header以伪类开头:hover {}相当于:hover以属性选择器开头[data-disabled] {}相当于[data-disabled]以组合器开头 .icon {}相当于 .icon注意伪元素我没有列进去。虽然部分浏览器也支持::before {}这种隐式写法但它作为独立选择器本来就合法在旧版解析里容易被理解成“全局所有元素的before”歧义很大。我的建议是涉及伪元素一律显式写::before这能让兼容性和可读性都更稳。必须显式写的情况以类型选择器开头div、span、input、button这些元素名看这个例子这是最容易翻车的写法/* 坑写法你以为在嵌套其实是全局规则 */ .form { input { border: 1px solid #ccc; } }因为input是类型选择器浏览器不认为它是嵌套会把整条规则当成普通全局规则处理实际效果等价于input { border: 1px solid #ccc; }页面上所有input都会中招。正确写法是.form { input { border: 1px solid #ccc; } }我把常见的隐式嵌套情况整理成了表格可以直接收藏。内层选择器写法是否隐式嵌套展开结果备注.title是.card .title类选择器可隐式#header是.card#headerID选择器可隐式:hover是.card:hover伪类可隐式[data-x]是.card[data-x]属性选择器可隐式 .icon是.card .icon组合器可隐式::before建议显式.card::before为避免歧义显式写div否全局div类型选择器必须显式写提示如果没有把握所有嵌套规则都显式写一定没错。隐式嵌套省几个字符但代价是理解门槛和边界规则都更高。多人协作的项目里统一显式往往是更稳的选择。2.3 的进阶用法它比想象中灵活不只是个前缀占位符它可以出现在选择器中的任意位置也可以多次出现。下面是几个非常实用的场景。第一个追加类名.card { .active { border-color: #4a90d9; } }展开后是.card.active这种写法比.card.active {}读起来更直观激活状态、禁用状态都和主规则绑在一起。第二个兄弟选择器.card { { margin-top: 16px; } }展开后是.card .card专门处理“连续多个卡片之间的间距”不用再单独给后一个卡片造一个类名。第三个反向约束父容器环境.card { .theme-dark { background: #1e1e1e; } }展开后是.theme-dark .card {}意思是“当卡片处于.theme-dark容器内时背景变深色”。这个写法特别适合做主题切换你不用在HTML里给每个卡片单独加一个判断类只需要在最外层容器上标记一个环境类子组件的样式规则就能通过反向嵌套自己适配。比起以前把主题类名手动拼到每个子组件的选择器里这种方式维护起来轻松得多。第四个组合使用.btn { :not(:disabled):hover { transform: translateY(-1px); } }展开后是.btn:not(:disabled):hover一个选择器把状态条件全部挂好可读性很强。2.4 Sass式“字符串拼接”在原生嵌套里不可用这个坑一定要单独拎出来说。在Sass里很多同学习惯写这种代码.card { __header { font-size: 18px; } __body { padding: 12px; } }Sass会把__header拼接成.card__header很好用。但原生CSS嵌套不支持这种字符串拼接。在原生CSS里__header是一个无效的选择器浏览器会直接把整条规则丢掉样式不生效但也不报错排查起来极其隐蔽。如果你是从Sass迁过来的项目第一件事就是戒掉这种“后面直接跟一串字符”的写法。原生嵌套里要写完整类名比如.card { .card__header { font-size: 18px; } }或者干脆调整类名策略让嵌套语法真正发挥作用我后面第4节会展开讲。3. 嵌套展开逻辑与特异性别把嵌套当成无脑缩进3.1 浏览器到底怎么展开 符号很多人以为嵌套就是简单的字符串替换其实不完全是。规范规定在展开时会被父选择器替换而父选择器通常会包进一个:is()里。比如.card { .title { color: red; } }实际展开逻辑是:is(.card) .title { color: red; }单个选择器时:is(.card)和.card没区别你不用关心。但父选择器是选择器列表时差异就来了.card, .panel { :hover { color: red; } }展开为:is(.card, .panel):hover { color: red; }这个写法等价于传统手写的.card:hover, .panel:hover匹配结果一致。但注意这里面藏着一个特异性陷阱下面细讲。3.2 特异性陷阱:is() 会“取最大值”:is()的特异性规则比较特殊它的特异性等于参数列表里特异性最高的那个选择器。这句话意思是当你把一个包含ID选择器的列表作为父选择器时嵌套的子规则会继承这个高特异性。举个例子#container, .card { .title { color: red; } }展开成:is(#container, .card) .title。:is(#container, .card)这部分会取#container的特异性也就是一个ID的权重而不是.card的权重。所以最终这个.title的规则特异性比很多人预期的要高——直接到了ID级别。这在项目里带来的实际问题是如果你在嵌套里用了一个诸如#app .wrapper这样的父级环境选择器那么嵌套出来的所有子规则都有很高的特异性事后想用一个普通的类选择器去覆盖它可能压不住只能跟着写更长的选择器或者上!important。我平时会遵循两条经验嵌套里的父选择器尽量保持“纯净”不要在最外层嵌套规则里混入ID选择器。嵌套深度控制在2到3层以内。嵌套把HTML结构“映射”进了CSS同时也会让特异性像叠buff一样叠加层级越深后期覆盖越痛。3.3 嵌套媒体查询样式跟着组件走嵌套不仅适用于选择器也适用于media这样的条件规则。比如一个卡片在桌面端和移动端的栅格列数不同传统写法要把媒体查询单独拆到文件底部隔了老远还要回头找选择器。有了嵌套之后可以直接把断点样式写进组件块内部.card { display: grid; grid-template-columns: 1fr; media (min-width: 600px) { grid-template-columns: repeat(2, 1fr); } }这样组件在哪个断点下变成什么布局一屏之内就能看完不需要上下翻文件。media内部如果要继续嵌套选择器规则和前面完全一样类型选择器依然要显式写。这个能力对长期维护特别友好尤其是响应式组件多的时候真正做到了“组件样式内聚”。4. 实战案例把一段传统CSS改成嵌套写法4.1 原始代码的问题假设有一个“个人中心”卡片组件传统写法如下这已经算是比较清爽的平铺了.profile { border: 1px solid #e5e5e5; border-radius: 12px; padding: 24px; } .profile__avatar { width: 64px; height: 64px; border-radius: 50%; object-fit: cover; } .profile__name { font-size: 18px; font-weight: 600; } .profile__desc { font-size: 14px; color: #666; } .profile__desc:first-line { color: #999; } .profile__tags { display: flex; gap: 8px; margin-top: 16px; } .profile__tags .tag { background: #f0f0f0; border-radius: 4px; padding: 4px 8px; } .profile__follow { margin-top: 20px; background: #4a90d9; color: #fff; border: none; border-radius: 6px; padding: 8px 16px; cursor: pointer; } .profile__follow:hover { background: #356bb5; } .profile__follow:disabled { background: #ccc; cursor: not-allowed; }问题很明显profile前缀重复写了十几次.profile__tags .tag这种后代关系要靠人脑去维护hover和disabled状态另起一段跟主样式离得很远改一个按钮的配色要同时改好几处。4.2 嵌套改写后的样子用嵌套改写之后代码变成这样.profile { border: 1px solid #e5e5e5; border-radius: 12px; padding: 24px; .avatar { width: 64px; height: 64px; border-radius: 50%; object-fit: cover; } .name { font-size: 18px; font-weight: 600; } .desc { font-size: 14px; color: #666; ::first-line { color: #999; } } .tags { display: flex; gap: 8px; margin-top: 16px; .tag { background: #f0f0f0; border-radius: 4px; padding: 4px 8px; } } .follow { margin-top: 20px; background: #4a90d9; color: #fff; border: none; border-radius: 6px; padding: 8px 16px; cursor: pointer; :hover { background: #356bb5; } :disabled { background: #ccc; cursor: not-allowed; } } }注意我把HTML里的类名从profile__avatar这种BEM双下划线模式简化成了.avatar、.name、.tag这样的短类名因为组件根节点.profile已经提供了上下文。这样做的收益是样式代码几乎没有冗余hover、disabled状态直接挂在主规则下面看代码时一目了然。改动某个子元素时所有相关样式都在同一个代码块里不用满文件翻。4.3 嵌套对命名方案的影响说点实在的观察这个案例你会发现原生嵌套天然鼓励“短类名 后代关系”的写法而不是冗长的BEM双下划线。这对中小型项目很友好。但如果你维护的是大中台项目组件可能被外部引用或者有全局样式覆盖的需求BEM依然有它的存在价值。嵌套只是组织方式不代表你可以完全无视命名对架构的影响。我见过两种都跑得很好的模式小项目、原型项目短类名 嵌套开发速度极快。组件库、大型业务外层保留语义化组件名内部用嵌套精简重复前缀但依然保持稳定的命名规范。所以我的建议是先定命名规范再谈嵌套方式。嵌套解决的是“怎么写省力”的问题命名解决的是“怎么找得着”的问题两个都重要别只抓一头。5. 原生嵌套与 Sass/LESS 的差异它们真不是一回事5.1 功能对比很多同学会问Sass已经嵌套了这么多年原生CSS嵌套还有什么意义我的回答是少一层构建、零工具链、浏览器直接解析。对于学习CSS本身、写静态页面、做小型原型来说原生嵌套把“依赖Node生态”这一步整个省掉了。但我必须强调原生嵌套和Sass嵌套在功能上差距很明显特性原生CSS嵌套Sass嵌套父选择器引用支持支持隐式省略部分支持类型选择器不行支持语义更自由拼接字符串-title不支持支持extend/mixin不支持支持at-root逃逸不支持支持嵌套media支持支持处理器/插件体系无丰富最要命的就是-title拼接前面已经提过。原生CSS一旦遇到这种写法直接判定无效规则丢掉既不报错也不生效排查成本高。从Sass迁回原生之前代码里如果有大量这种拼接先想好替代方案。5.2 工程选型建议如果你是新建项目浏览器目标基本是近两年版本可以放心用原生嵌套。如果你需要兼容旧浏览器或者重度依赖Sass的mixin、extend体系那继续用Sass别为了时髦硬切。这里多提醒一句用Sass时如果嵌套里写了类似原生CSS的隐式嵌套两者的处理细节有差异特别容易混用出错。团队最好在代码规范里明确要么统一用原生嵌套语法并通过构建工具编译要么统一用Sass嵌套不要在一个文件里混着写不然排查样式问题的时候谁看谁崩溃。5.3 迁移低成本路线写作风格先行如果你想先从Sass平稳过渡到原生嵌套我推荐一个比较顺的路线先把Sass里-拼接这类写法改造掉改成完整类名再删掉Sass的嵌套特殊语法只保留原生兼容的嵌套方式最后跑一下Lightning CSS之类的工具做编译。整个过程可以分步骤推进不必一次性把所有代码全部改完也不会出现“改到一半样式崩了”的尴尬。6. 避坑指南上手原生嵌套最容易遇到的6个坑6.1 高频坑速查这里把我实操中见过的高频坑整理成一个速查表建议存一下。坑现象解决方法类型选择器开头被当全局写了div {}结果全站div都被影响类型选择器必须显式写 div-title拼接选择器样式不生效且不报错原生不支持拼接写成完整类名选择器列表里混入类型选择器整个规则可能被当全局规则处理列表里每个项都显式写嵌套层级过深特异性过高后面覆盖不掉控制嵌套不超过2-3层用类名代替层级旧浏览器不识别嵌套内层规则被忽略或误解用构建工具编译或回退传统写法隐式嵌套被误解以为.child会被嵌套实际走了全局规则先查规则表统一显式6.2 兼容性回退方案如果你的项目还要兼容2023年底之前的旧浏览器又想在开发时用原生嵌套有两条路可以走一是继续用Sass但把嵌套规则限制在原生兼容的范围内以后迁移成本低代码风格也贴近标准。二是使用构建工具比如Lightning CSS它能识别原生嵌套并编译成传统CSS顺带还能做压缩、自动加前缀。跑一下构建流程原生嵌套的源码就能兼容到老浏览器开发体验和兼容性兼得。还有一个小细节如果你用supports写渐进增强可以判断浏览器是否支持嵌套再决定要不要输出增强样式。不过大多数项目会用构建工具统一处理对于纯静态页面我个人认为检查“目标用户浏览器版本”比写复杂回退更实际。6.3 新手最容易忽略的协作规范问题最后聊一个代码之外的坑。嵌套让CSS写起来爽了但如果团队没有约定嵌套深度和命名规范代码会很快变成“俄罗斯套娃”——每个组件里三层外三层的缩进看起来像优化了实际维护起来比平铺还痛苦。我建议项目里定一些硬性规矩嵌套不超过3层状态伪类尽量直接挂在组件根选择器上一个文件里只维护一个组件。这些规矩不是CSS本身的限制而是为了让你和三个月后的自己都还能看懂这份代码。另外在多人协作的代码评审里嵌套规则经常会引发一个争议到底该用隐式嵌套还是显式。我的倾向很明确类型选择器必须显式其他看团队习惯但同一个文件内要一致。隐式嵌套确实省字符可一旦有人分不清边界踩了类型选择器的坑排查成本远大于省下的那点打字时间。最后谈一点使用体会从Chrome 120支持之后我在新项目里基本就全面切原生嵌套了。头一个月最大的收获还不是代码写起来多爽而是“选择器阅读成本”下来了缩进即层级看到嵌套结构基本就能还原出组件的HTML骨架算是真正的“所见即所得”。不过我也吃过亏比如刚开始没注意类型选择器的限制写了一个input嵌套结果全站表单样式都飘了排查了半天才反应过来是嵌套解析的问题。后来养成了习惯所有元素选择器一律显式不玩隐式缩写省心很多。如果你要试我建议从小型组件开始保持嵌套层级不超过两层状态伪类挂在最近的组件根上这样既享受了简洁又不至于给自己埋雷。下一篇我会继续聊CSS里另外一个组织样式的实用特性这里先卖个关子等发出来咱们接着聊。