合并CSS会拖慢首屏渲染，因全部样式均阻塞渲染，即使80%仅用于非首屏；应提取critical.css内联，并异步加载非关键CSS。
为什么合并CSS文件反而可能拖慢首屏渲染
合并CSS确实能减少HTTP请求数，但现代浏览器对小文件的并行加载能力很强，而关键问题是：所有合并后的CSS都会阻塞渲染，哪怕其中80%的样式只用于滚动到底部才出现的模块。用户点开页面时，header.css、product-grid.css、modal.css全被塞进一个app.css里，浏览器必须下载、解析、构建CSSOM后才能画第一帧。
实操建议：
- 把首屏必需的样式（如导航栏、主标题、首张图布局）抽成
critical.css，内联在里 - 非首屏CSS用
rel="preload"异步加载：<link rel="preload" href="non-critical.css" as="style" onload="this.rel='stylesheet'">
- 避免用
@import合并——它会强制串行加载，比多一次RTT
压缩CSS时display: none和visibility: hidden会被误删吗
不会。标准CSS压缩工具（如cssnano、clean-css）只删空格、注释、重复规则、无效声明（比如color: red; color: blue;中前者），不会动语义性声明。但要注意：某些“激进”模式（如discardUnused: true）会基于HTML分析删除未使用的类名——如果某个.hidden-section只在JS动态添加时才生效，压缩器可能误判为“没用”，把它连同display: none一起干掉。
实操建议：
- 关闭压缩工具的
discardUnused选项，或显式保留关键类：/* purgecss start ignore */ .js-only-hidden { display: none; } /* purgecss end ignore */ - 用
visibility: hidden替代display: none做占位时，确保它真被用到——否则压缩器可能认为整条规则冗余 - 上线前用
curl -s your-site.com | grep "display: none"快速扫一遍关键隐藏逻辑是否还在
媒体查询合并后，@media (min-width: 768px)在小屏设备上还生效吗
会生效，但代价是：小屏设备仍要下载、解析全部断点内的CSS，哪怕其中90%是max-width: 1024px以下完全用不到的规则。这不仅浪费带宽，更延长CSSOM构建时间——浏览器得逐条判断每条规则的媒体条件是否匹配当前视口。
实操建议：
- 按断点拆分文件，用
media属性做条件加载：<link rel="stylesheet" href="mobile.css" media="max-width: 767px"><br><link rel="stylesheet" href="desktop.css" media="min-width: 768px">
- 慎用
prefers-reduced-motion等新特性混在大文件里——旧浏览器虽忽略它，但仍要解析整段文本，增加解析负担 - Webpack用户可用
postcss-preset-env配合postcss-import，让@import支持media参数，实现编译期条件引入
PostCSS插件链中cssnano和autoprefixer谁该在前
autoprefixer必须在cssnano之前。因为cssnano会把display: flex压缩成display:flex，而autoprefixer需要识别完整声明才能插入-webkit-box等前缀；如果顺序反了，前缀就加不上。
实操建议：
- PostCSS配置顺序固定为：
autoprefixer→postcss-preset-env→cssnano - 检查
cssnano版本——v5+默认启用svgo压缩内联SVG，可能意外移除<use></use>引用的id，导致图标不显示 - 本地开发禁用
cssnano，用postcss-reporter输出压缩率报告，避免“越压越大”（比如base64图片被重复编码）
真正卡顿的往往不是CSS体积本身，而是浏览器不得不为“可能用到”的样式做大量无谓工作——解析、匹配、重排。优化重点不在删多少字节，而在让浏览器第一眼就知道：“这些，现在就要；那些，先放着。”
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
