CSS性能问题核心在渲染阻塞、选择器匹配耗时与重排重绘失控；@import因串行加载阻断并行，深层后代选择器（如.header .nav li a）从右向左匹配导致效率骤降，width/height等属性触发高开销重排，内联关键CSS需精准提取首屏最小规则集而非全量注入。
CSS 性能问题不是“有没有”，而是“卡在哪”——多数页面慢，根本原因不是 JS 或图片，而是 CSS 阻塞渲染 + 选择器匹配耗时 + 重排重绘失控。优化必须从加载、解析、应用三个环节下手，不能只压缩文件。
为什么 @import 比 <link> 更危险
它不只是“加载晚”，而是会阻断并行下载：<link> 在 HTML 解析阶段就发起请求，浏览器可并发加载；@import 必须等上一个 CSS 文件解析完才开始加载下一个，形成串行链。更糟的是，它在 CSS 文件内部使用时（比如 @import url("base.css");），会把整个依赖树拖进单线程解析流中。
- 现象：首屏白屏时间明显延长，DevTools 的 Network 面板里 CSS 请求呈“阶梯状”排列
- 场景：老项目迁移、UI 库二次封装、Sass 中滥用
@import替代@use - 替代方案：全部改用
<link rel="stylesheet">；Sass 中优先用@use+@forward，避免运行时拼接
.header .nav li a 这类深层后代选择器为什么拖慢渲染
浏览器匹配 CSS 选择器是“从右到左”执行的。对 .header .nav li a，它先找所有 <a></a>，再逐个向上检查父级是否含 li、再是否含 .nav、最后是否在 .header 内——DOM 越大，匹配成本指数级上升。
- 关键点：
a是关键选择器（rightmost selector），但它的数量最多，筛选基数太大 - 安全深度：生产环境建议控制在 3 层以内，如
.nav-link>.nav-item>.nav，用语义化 class 替代标签嵌套 - 避坑：不要写
div ul li a，哪怕 DOM 结构真长这样——浏览器不关心结构，只关心匹配效率
哪些 CSS 属性一改就触发重排（reflow）
重排 = 浏览器重新计算整个渲染树的几何信息，开销远高于重绘。只要改动影响布局尺寸或位置，就大概率触发重排。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 高危属性：
width、height、padding、margin、border、top/left（非transform）、display、font-size - 低危替代：
transform和opacity只触发合成（composite），不触发布局计算；动画优先用transform: translateX(10px)而非left: 10px - 隐藏陷阱：
offsetHeight、getComputedStyle()强制同步布局，连续读写会引发“布局抖动”（layout thrashing）
内联关键 CSS 后，怎么避免体积失控
内联能消除首屏 CSS 请求阻塞，但把整张 main.css 塞进 <style></style> 里，HTML 体积暴涨，且失去缓存能力——HTTP/2 下尤其得不偿失。
- 正确做法：只提取首屏可见区域（above-the-fold）所需的最小规则集，例如
.hero、.logo、.primary-cta对应的样式 - 工具推荐：
PurgeCSS+critical（Node CLI）自动提取；Webpack 项目可用critters插件 - 注意边界：不要内联字体声明（
@font-face）、媒体查询（@media）或第三方组件全量样式——它们无法被精准判定为“首屏必需”
真正难的不是知道该做什么，而是判断“哪些 CSS 算关键”——这必须结合真实设备视口、首屏 DOM 结构、以及用户实际滚动行为来测量，不能靠经验拍脑袋。
