应合并CSS文件并按需加载：开发时分文件便于维护，构建时用Webpack/Vite等工具自动合并；非首屏样式用media或onload动态加载；关键CSS内联需控制在14KB内，避免Base64和重复内联；HTTP/2下仍建议合并以提升缓存命中率和减少头部开销；排查重复打包需统一路径、禁用第三方库冗余样式引入，并检查构建配置。
多个CSS文件导致页面加载慢怎么办
直接合并或内联，别让浏览器发起十几次HTTP请求去拉十几个.css文件。现代浏览器对同域并发请求数有限制（HTTP/1.1 通常6个），多文件会排队，首屏渲染卡在最后那个style.css上。
实操建议：
- 开发阶段保留多个文件便于维护，构建时用工具自动合并——Webpack 的
MiniCssExtractPlugin、Vite 的默认行为、Rollup 的rollup-plugin-css-only都能干这事 - 确认是否真需要拆：比如
print.css、theme-dark.css这种非首屏必需的，用media或onload动态加载，别放里直接link - 检查构建产物：打开
dist/目录，看最终输出是不是只剩1–2个.css文件；如果还有七八个，说明打包配置没生效或被import方式绕过了
CSS内联该用在哪些地方
只内联「首屏关键样式」（Critical CSS），不是把所有CSS都塞进<style></style>标签。内联太多反而拖慢HTML解析，还无法缓存。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 手动复制粘贴整份
main.css到里 → HTML体积暴涨，gzip失效，TTFB变长 - 内联了
@font-face或大尺寸background-image: url(data:...)→ Base64编码后体积翻倍，得不偿失 - 服务端渲染时每次请求都重新生成Critical CSS → CPU白耗，不如静态化
正确做法：
- 用
critters（Vite插件）或penthouse（Webpack）自动生成，它会模拟首屏视口，提取真正用到的选择器 - 内联内容控制在~14KB以内（TCP初始拥塞窗口常见值），避免分包传输
- 搭配
preload：对非关键CSS用<link rel="preload" as="style" href="non-critical.css" onload="this.rel='stylesheet'">
HTTP/2 或 HTTP/3 下还要合并CSS吗
要，但优先级降低。HTTP/2支持多路复用，多个.css请求不再排队，但每个文件仍有TLS握手、HTTP头开销、缓存粒度等问题。
性能影响点：
- 每个
.css文件都是独立缓存单元：改一个按钮颜色，就得让全部用户重新下载整个button.css，而合并后只有app.css更新，CDN缓存命中率更高 - HTTP/2头部压缩虽好，但
Link: <style.css>; rel=preload</style.css>这类字段仍占字节，文件越少，头部总开销越低 - Service Worker拦截
fetch时，处理1个请求比处理8个更稳，失败重试逻辑也简单
所以结论不是“不用合并”，而是“合并 + 按需加载”双策略：主包合并，异步功能模块（如dashboard-widget.css）按路由动态import。
Webpack里CSS被重复打包了怎么查
典型表现是最终bundle.css里出现两遍.btn { ... }，或者Chrome DevTools的Network面板看到同一个index.css被加载两次。
原因和解法：
- 检查
import路径是否不一致：比如./index.css和../src/index.css在Webpack眼里是两个模块 → 统一用绝对路径或别名（@/styles/） - 第三方UI库（如
antd）自带CSS，你又在入口里import 'antd/dist/reset.css'，同时组件内部也import了 → 关闭库的样式自动引入，改用全量导入或按需加载插件 -
MiniCssExtractPlugin和style-loader混用：开发用style-loader注入<style></style>，生产用MiniCssExtractPlugin抽离，但如果配置漏掉rules.oneOf条件判断，可能两边都生效 → 确保test: /\.css$/规则只匹配一次
最简单的验证方式：npx webpack --stats=verbose | grep -A5 "css"，看模块依赖图里有没有重复节点。
