SSR 中 CSS 选择器“失效”是因服务端无 DOM 上下文，无法解析含伪类、动态属性或结构推断的选择器，导致规则被静默跳过并输出“1 rules skipped due to selector errors”日志。
SSR 页面中 CSS 选择器“失效”或“匹配异常”，通常不是选择器写错了，而是服务端解析时根本无法识别 DOM 上的动态属性、伪类或某些结构——1 rules skipped due to selector errors 这类日志就是明确信号。
为什么 SSR 会跳过你的 CSS 规则？
Angular Universal（或其他 SSR 框架）在服务端没有真实 DOM，只能靠静态 HTML 字符串和预定义规则做 CSS 解析。一旦遇到它无法安全处理的选择器，就会直接跳过整条规则，不报错、不警告，只在日志里留一句 1 rules skipped due to selector errors。
-
div[!invalid-attr="test"]：含非法字符（如!）的属性名，服务端解析器直接拒识 -
a:visited { color: purple; }：:visited在 SSR 中无访问历史可查，被当成无效伪类丢弃 -
.card > .header + p::before：含::before伪元素的选择器，在服务端无渲染上下文，多数 SSR 工具链会静默忽略 -
input[type="number"]:focus：组合了用户交互态（:focus）与属性选择器，服务端无法模拟焦点状态，整条规则被判定为“不可预测”而跳过
哪些选择器在 SSR 中最危险？
不是所有“看起来合法”的选择器都能过 SSR 这关。以下三类是高频雷区：
-
含运行时依赖的伪类：
:hover、:focus、:active、:visited—— SSR 不执行 JS，也不触发用户行为，这些伪类在服务端无意义 -
依赖 DOM 结构推断的选择器：
:first-child、:nth-of-type(2)、:empty—— 服务端不知道最终渲染出多少子节点，无法安全计算 -
含非法或模糊值的属性选择器：
[data-id=123abc]（未加引号，且以数字开头）、[class~="btn"]（空格分隔匹配，SSR 解析器可能不支持）
怎么安全地写 SSR 友好的 CSS？
核心原则：只用服务端能静态确认存在、类型明确、值确定的特征来选中元素。
立即学习“前端免费学习笔记（深入）”；
- 优先用
class和id选择器，它们在 SSR 中 100% 可控；避免嵌套过深（如.layout .main .content .title），既降低权重也减少 SSR 解析负担 - 属性选择器必须加引号：
[data-role="modal"]✅，[data-role=modal]❌（尤其当值含数字、短横线或特殊字符时） - 需要状态样式？改用显式 class 控制：
.button--loading替代.button:disabled；让 JS 或服务端逻辑决定是否加这个 class - 媒体查询本身没问题，但别在里面塞
:hover：@media (min-width: 768px) { .nav:hover { } }是高危写法；应拆成@media (min-width: 768px) { .nav--hoverable { } }
如何快速验证某条 CSS 是否会被 SSR 跳过？
不用等部署，本地就能测：
- 启动 SSR 构建（如
ng run myapp:server），观察控制台日志是否出现rules skipped提示 - 打开生成的
dist/server/main.js（或对应 SSR bundle），搜索你写的 CSS 规则字符串 —— 如果完全没出现，大概率已被预处理器过滤 - 在浏览器中查看源代码（Ctrl+U），搜索目标 class 或属性 —— 如果 HTML 中已存在，但对应样式没出现在内联
<style>或预加载的 CSS 中，说明那条规则被跳过了
真正麻烦的不是“样式没生效”，而是它悄无声息地消失——你得盯着日志、翻构建产物、比对源码，才能确认那条规则到底有没有被 SSR 吃掉。
