多个link标签并行加载不必然慢，但默认阻塞渲染且受HTTP/1.1并发限制易串行；HTTP/2下改善但仍建议合并关键CSS、按路由拆分、避免@import、确保CDN正确识别contenthash变更。
多个 link 标签并行加载是否真慢？
不是必然慢，但默认行为下容易触发“阻塞式串行”，尤其在旧版浏览器或 HTTP/1.1 环境中。link 标签本身是阻塞渲染的（除非加 media="print" 或 rel="preload"），且浏览器对同一域名的并发连接数有限制（HTTP/1.1 通常为 6）。如果写成多个普通 ，它们会排队等待 DNS、TCP、TLS，再逐个发请求。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- HTTP/2 环境下，多个
link并发效果较好，但仍建议合并关键样式（如首屏 CSS）避免过多请求头开销 - 对非关键 CSS（如后台管理页、打印样式、主题切换样式），用
rel="stylesheet" media="print"占位，后续用 JS 切换media值来激活 - 避免在
底部堆砌 5+ 个link，哪怕它们体积小——每个都触发一次 fetch 微任务调度
rel="preload" 加载 CSS 后怎么避免重复解析？
直接写 不会自动应用样式，必须手动插入 ，否则白屏或闪动。常见错误是预加载后忘了挂载，或重复挂载导致两次解析。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 预加载后用
onload回调插入实际样式节点： - 不要对同一 URL 多次
preload，Chrome 会警告Resource was preloaded using link preload but not used within a few seconds - 服务端渲染（SSR）场景下，若已内联关键 CSS，
preload的完整 CSS 应设为media="unmatched"，防止早期触发 FOUC
Webpack/Vite 中 CSS 提取与 chunk 分离的实际取舍
打包工具默认把 CSS 提取成独立文件（mini-css-extract-plugin 或 Vite 的 build.cssCodeSplit），但这不等于最优。拆太碎会导致 HTTP 请求增多；全打到一个文件又影响缓存复用和首屏加载。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 按路由/页面维度拆分：Vite 中配置
build.rollupOptions.output.manualChunks，把src/views/Home/index.css和src/views/User/index.css分别打进对应 chunk - 禁用「组件级 CSS 提取」：Vue 的
或 React 的 CSS Modules 默认仍走 JS 注入，不要额外配extractCSS: true，否则每个组件生成一个 CSS 文件 - 警惕
@import：Webpack 中@import会打断提取逻辑，导致被 import 的文件无法单独成 chunk，改用import './xxx.css'显式声明依赖
CDN 缓存失效与版本号注入的坑
很多人用 filename: '[name].[contenthash:8].css' 以为就万事大吉，但 CDN 可能忽略 query 参数、缓存了带 hash 的路径却没清旧文件，或者构建时 contenthash 没变（比如只改注释），导致用户拿到过期样式。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 强制让 CDN 识别变更：在
link的href后追加?t=xxx（时间戳）或?v=xxx（构建 ID），但仅用于开发或灰度，线上仍以 contenthash 为主 - 检查 CDN 配置是否缓存了
.css的Cache-Control: public, max-age=31536000—— 这没问题，但要确保回源时 404 能正确返回（旧 hash 文件被删后，不能返回 200 + 空内容） - CI 流程中加校验：构建后执行
grep -r 'main\.[a-z0-9]\{8\}\.css' dist/index.html，确认 HTML 中引用的 hash 确实存在于dist/目录下
最常被忽略的是：CSS 文件本身没变，但其依赖的变量（比如 Sass $primary-color）变了，而构建工具未将变量文件纳入依赖图——此时 contenthash 不更新，CDN 就不会拉新文件。
