Sass、Less、Stylus 嵌套语法差异显著：Sass（SCSS）必须用 & 显式拼接父选择器；Less 自动挂载伪类但需注意变量作用域；Stylus 最自由但易因缩进歧义报错；PostCSS 需 postcss-nested 插件支持，且嵌套过深会推高 specificity 引发覆盖难题。
嵌套语法在 Sass、Less、Stylus 中怎么写才不报错
预处理器支持 CSS 嵌套，但不是所有写法都通用——Sass（SCSS）最宽松，Less 次之，Stylus 最自由但容易误用。关键区别在于：嵌套层级是否自动拼接选择器、伪类/伪元素是否需显式加 &、属性嵌套是否被允许。
常见错误现象：Invalid CSS after " color: red;": expected "{", was ";"（Less 把属性当选择器解析）、Undefined variable "$color"（Sass 中变量未声明就嵌套引用）。
- Sass（SCSS）中必须用
&显式表示父选择器，比如&:hover、&__item；直接写:hover会生成独立规则 - Less 不强制用
&，:hover会被自动挂到父选择器后，但.btn:hover和.btn { &:hover }编译结果一致；若想脱离父级，得用@{selector}或提前解构 - Stylus 允许省略大括号和冒号，但嵌套时若混用缩进与花括号，会因解析歧义报错；推荐统一用缩进，且避免跨多层缩进后突然换行写属性
Sass 的 & 符号为什么有时失效
& 是 Sass 嵌套里的“锚点”，代表当前选择器的完整前缀。它失效通常不是语法错，而是作用域或编译时机问题。
使用场景：写 BEM 类名、状态组合、媒体查询内复用父选择器。
立即学习“前端免费学习笔记（深入）”；
- 在
@media内部用&是安全的，比如.card { @media (min-width: 768px) { &--wide { width: 100%; } } }→ 编译为@media (min-width: 768px) { .card--wide { width: 100%; } } - 但在
@at-root或@keyframes里用&会报错，因为已脱离选择器上下文；此时应改用变量暂存，如$parent: ".card"; #{$parent}--active { ... } - 嵌套过深（>5 层）时，
&拼接出的选择器可能超长，部分旧版 IE 或 CSS-in-JS 库会截断或拒绝解析，建议用@extend或拆分为独立类名
PostCSS 能不能原生支持嵌套？需要哪些插件
PostCSS 本身不解析嵌套，必须靠插件。目前主流是 postcss-nested，但它和 Sass/Less 行为不完全一致——更接近 Sass 的语义，但默认不支持属性嵌套（如 font: { size: 14px; weight: bold; }）。
性能影响：开启嵌套解析会增加 AST 遍历次数，大型项目中构建耗时可能上升 8%–12%，尤其搭配 postcss-import 多层引入时。
- 必须安装并启用
postcss-nested，仅配置postcss-preset-env不够——后者默认关闭嵌套（nesting: false） - 如果用了
postcss-custom-properties，注意变量作用域：嵌套块内无法访问上层:root定义的--color，需改用var(--color)或提升变量定义位置 - 和 Autoprefixer 共用时，确保
postcss-nested在 Autoprefixer 之前执行，否则媒体查询内的嵌套可能漏加前缀
嵌套导致 specificity 过高怎么办
嵌套天然推高 CSS 优先级，比如 .header .nav .item .link:hover 比 .link.is-active 更难覆盖，这是最隐蔽也最常被忽略的问题。
兼容性影响：高 specificity 会阻碍组件化样式隔离，尤其在微前端或 Web Components 场景下，外部样式极易被内部嵌套规则压制。
- 用
postcss-specificity插件跑一遍构建报告，标出 specificity ≥ 0,2,0 的规则，重点审查是否真需这么深的嵌套 - 避免连续用类名嵌套，改用 BEM 的修饰符（
.menu__item--active）或数据属性（[data-state="open"]），它们 specificity 更低且语义清晰 - 开发阶段可临时加
!important快速验证，但上线前必须删掉——它掩盖的是结构问题，不是样式问题
嵌套不是语法糖，是选择器结构的显式声明。写的时候多想一层：这个嵌套，到底是描述 DOM 关系，还是仅仅为了少写几遍类名？后者往往就是坑的起点。
