SCSS @use 模块隔离导致伪类规则未编译进输出，因未显式 @forward 或 @use as *；伪类还易受嵌套上下文、特异性、LVHA顺序、:not()语法及DOM结构影响而失效。
SCSS @use 隔离导致伪类规则未被编译进输出
当你用 @use 引入一个 SCSS 模块（比如 @use 'base/buttons'），Dart Sass 默认启用模块作用域隔离——模块内定义的样式，除非显式导出（@forward 或 @use ... with），否则不会进入全局 CSS 输出。这意味着：如果按钮的 :hover、:disabled 等伪类写在 buttons.scss 里，但没加 @forward 'buttons' 或没在主文件中 @use 'buttons' as *，那整套交互状态规则压根不会出现在最终 CSS 中。
-
@use不等于@import：它不拼接源码，而是构建独立作用域 - 伪类规则若只写在模块内部且未被
@forward或调用，Sass 编译器直接跳过它们 - 检查编译后 CSS 文件，搜索
:hover或:disabled，若完全缺失，大概率是模块未正确暴露
:hover 和 :disabled 在嵌套模块中被错误包裹
常见误写是把伪类塞进父选择器嵌套块里，又没处理好层级关系。例如在 _forms.scss 中这样写：
.input-group {
input {
&:hover { border-color: #007bff; }
&:disabled { background: #f5f5f5; }
}
}
这本身没问题，但一旦这个模块被 @use 后又在另一个上下文（如 .modal .input-group）中复用，而你忘了给 .input-group 加 position: relative 或其他必要上下文，input:hover 就可能因父级 pointer-events: none、overflow: hidden 或 z-index 被遮挡而失效——不是伪类丢了，是触发条件被阻断。
- 伪类生效依赖可交互的 DOM 状态，模块化不改变这点，但会放大上下文遗漏的影响
- 嵌套过深（如
.dialog .form .field input:hover）易导致特异性过高，被其他模块的同名规则意外覆盖 - 移动端上
:hover在触摸设备默认不触发，若模块未配@media (hover: hover)条件包裹，就只剩“悬停无效”现象
伪类顺序（LVHA）在跨模块合并时被破坏
SCSS 模块各自编译再合并时，:link、:visited、:hover、:active 的声明顺序可能被打乱。比如 base/links.scss 定义了 a:visited，而 theme/dark.scss 又重写了 a:hover，且后者在编译顺序中靠后——结果 a:visited:hover 这种非法组合虽不会出现，但 a:hover 会覆盖 a:visited 的颜色，造成“点击后悬停变色异常”。更隐蔽的是，:disabled 若被写在 :hover 右侧（如 button:hover:disabled），整个选择器会被浏览器静默丢弃，而模块化让这种错误更难被一眼发现。
立即学习“前端免费学习笔记（深入）”；
- 每个模块应只负责自己状态逻辑，避免在模块内强行组合矛盾伪类（如
:disabled:hover） - 跨模块的伪类优先级必须靠明确的加载顺序控制，不能依赖“谁写得晚谁赢”
- 用 DevTools 的 “Force element state” 功能单独验证
:hover和:disabled是否能独立触发，比猜顺序更可靠
:not() 和结构伪类在模块间引用时语法断裂
当一个模块导出类似 %btn-base 占位符，另一个模块用 @extend %btn-base 并试图追加 :not(:disabled)，Sass 会把整个表达式当作文本拼接。结果可能产出 button:not(:disabled):hover（合法），也可能产出 button:hover:not(:disabled)（旧版 Safari 解析不稳定），甚至 button:not(:disabled, :loading)（逗号语法非法，整条规则被忽略）。这类问题在单文件里容易肉眼识别，模块化后却分散在不同文件，调试成本陡增。
-
:not()内只能接单一简单选择器，:not(:disabled:hover)是非法写法，会被浏览器跳过 - 推荐统一用
selector:not(:disabled):hover格式，避免语义歧义 - 结构伪类如
:last-child失效往往不是模块化导致，而是 HTML 实际结构与模块预期不符（比如循环末尾多了一个div），模块化只是让这个差异更难追溯
@use，而是伪类是否还在真实 DOM 上“站得住脚”——它需要正确的编译路径、干净的触发上下文、守规矩的书写顺序，以及跨模块时对语法边界的清醒认知。 
