文档站、营销落地页与手写 HTML 往往把第三方皮肤、设计令牌、活动页补丁堆进同一份样式表，最终只能靠 !important 或更高特异性“硬压”。CSS 层叠层（@layer）在作者源内引入显式优先级，它在特异性之前就决定了哪一组声明获胜，从而让工具类不必再武装到牙齿。本文面向交付 MPA 或静态生成 CSS、又没有运行时打包器的团队，并强调必须在真实 Safari/WebKit 上签字。排期时请结合 静态组件的容器查询 与 Safari Technology Preview 对比稳定版 一起安排质检。
层叠层不会减少浏览器解析的声明条数，但能显著减少“谁覆盖谁”的心智负担；渐进增强仍要保留——不支持 @layer 的环境应仍能阅读核心内容。
心智模型：层在特异性之前
级联对声明的排序是固定的：先来源与重要性，再层顺序，然后特异性，最后源顺序。把规则写进 @layer utilities { … } 后，该块中所有声明作为一个整体参与比较。于是 utilities 里单类选择器也能压过 reset 里长链选择器，因为层比较更早发生。静态站点若把 Tailwind 或自研原子类正确放进 utilities，就可以删掉大量防御性 !important——前提是不要把半套框架留在未分层区域。
/* 入口 CSS 顶部只声明一次顺序 */
@layer reset, vendor, components, utilities;
@import "normalize.css" layer(reset);
@import "legacy-cms.css" layer(vendor);
@layer components {
.card { border-radius: 12px; }
}Eleventy、Hugo、Astro 静态输出应保证每个最终 CSS 只有一份“层清单”。多处重复 @layer 声明无害，但若局部片段各自列出冲突的顺序表，半年后无人能懂。把层清单当契约：重命名或调整顺序时写变更日志。
层顺序决策表
评审时若有人问“这个 SaaS 小部件放哪？”答案很少应该是“未分层，因为很小”。
| 来源 | 推荐层 | 理由 |
|---|---|---|
| Normalize / 现代重置 | reset | 普通优先级最低，不应压过组件。 |
| 供应商 UI、旧 CMS | vendor | 隔离历史债务，可按供应商版本整体替换。 |
| 产品组件（卡片、导航） | components | 稳定类名的自有模式。 |
| 间距、色板、活动实验 | utilities | 可预期的覆盖层。 |
| 线上紧急热修 | 未分层（临时） | 会赢过分层规则；必须挂工单迁到 utilities。 |
省略 vendor 层时，市场部门嵌入的迷你 CSS 往往把特异性战争带回主站。给这类文件单独一层，并在清单里排在 utilities 之前，设计同事才能用原子类改边框色而不用碰内联脚本。
未分层与分层作者 CSS
未分层的作者规则在普通重要性下排在所有分层规则之后，是强力但危险的逃生舱：本地 Chrome 看起来一切正常，问题只在 Firefox/Safari 的导入顺序边缘情况里冒头。静态站点应尽量单一入口打包，生产环境避免深度运行时 @import，否则 FOUC 与层顺序会随网络抖动变化。
迁移策略：新样式先进层，遗留整体暂留未分层；基线测试通过后再分批搬进 vendor 或 components。监控体积——层本身几乎不增字节，删掉的重复选择器才会减负。对预览环境跑 Lighthouse：LCP 未必变，但 CLS 可能因冲突 margin 消失而改善。
!important 陷阱
!important 不会绕过层。在作者源内，important 比较会反转层顺序：较早声明层里的 important 反而压过较晚层的 important。旧 CMS 里习惯用 important 当锤子的人，分层后会发现“关键热修”突然输给 reset 里的 important。正确做法是去掉 important 或把规则移到合适层，而不是在 utilities 再叠一层 important。
用户代理与用户样式仍遵循各自来源规则；不要为了“盖过”无障碍样式去钻层空子。结合 容器查询 做组件缩放时，要确保焦点环在查询容器收缩后仍满足对比度。
重置、组件、工具类
- reset：盒模型、排版默认值、元素归一；不要写品牌色，保持结构级。
- vendor：无法逐行审计的第三方 CSS；文件名带版本号便于 diff。
- components：BEM 块、Web 组件的无 Shadow 回退、跨语言复用的静态 partial。
- utilities：原子类与活动覆盖；限制每条工具声明的属性数量，避免变 INLINE 灾难。
在 README 写明层清单，外包同事才知道新英雄区该放哪。静态站失败常见原因不是缺功能，而是两个 card 实现同页互殴——分层让胜者可预测。
性能上浏览器仍要匹配每条选择器；层只优化级联阶段。配合浅 DOM 与谨慎 defer 非关键 CSS。安全方面层不消毒 HTML，转义仍在服务端。
浏览器矩阵
| 引擎 | @layer | 静态质检提示 |
|---|---|---|
| Chromium 99+ | 稳定 | 开发者工具展示层树，适合 CI 截图基线。 |
| Safari 15.4+ | 稳定 | 小版本需回归；WebKit 修复常先出现在 STP。 |
| Firefox 97+ | 稳定 | 导入重排层时警告清晰。 |
| 旧 WebKit（如 iOS 14） | 无 | 把层当作增强，核心排版不得依赖层。 |
企业静态站遥测里仍有约 6–9% 浏览器无层支持，每季度验证回退。
云 Mac 上的 Safari 流程
Linux CI 无法认证次像素抗锯齿与 WebKit 字体回退。每周留 30–45 分钟 真机：稳定 Safari 做合同级签字，Safari Technology Preview 查 WebKit 新修复。Web Inspector 级联面板展开截图，方便设计看清哪一层获胜。
采购卡硬件时可租 Apple Silicon Mac mini：SSH 部署、VNC 看 Safari， risky 操作前做快照。短租日均约 16.9 美元，比国际邮寄样机便宜。预览环境镜像生产 Content-Security-Policy，让分层 @import 失败提前暴露。
国际化：RTL 与逻辑属性混用时，层冲突表现为轻微 padding 翻转而非硬错误，阿语希伯来模板要在稳定 Safari 与 STP 双测。打印样式应去掉假设深色背景的 utilities，用 @media screen 包裹彩色令牌。
流程上每个 PR 附两分钟 Safari 与 Chromium 双录屏；发布说明记录 Safari 构建号与层清单版本，方便对照工单。无障碍评审在层重构后要重跑 VoiceOver：outline 可能从 components 挪到 utilities，动画时长也会变。
市场常喊“再多一版”英雄区；层能防止实验污染核心组件，但未分层热修仍要有工单号，便于代码搜索追责。分析团队若追踪样式实验，请在层迁移前后分段采样，避免把性能波动误读为营销效果。
最后，静态 CDN 上的缓存策略要与层清单版本联动：文件名哈希变更时清边缘节点，否则用户会短时间看到半新半旧的层顺序。运维可把层清单版本写进健康检查响应头，快速判断灰度是否一致。
常见问题
层叠层会取代特异性吗？
不会。层是更靠前的排序键；同一层内仍比较特异性，继承规则不变。
!important 与 @layer 如何相互作用？
作者源内 important 按层顺序反转比较；优先删除 important 而不是继续堆叠。
可以把分层 CSS 与未分层遗留文件混用吗？
可以，但未分层普通声明会压过分层声明——谨慎使用并计划迁移。
Mac mini 仍是 WebKit 质检的安静基准：色彩准、输入法原生、长时间跑 Safari 发热可控。MacHTML 提供裸金属 Apple Silicon 租用与 SSH/VNC，静态团队可在冲刺期租机取证，通过后即释放资源。