Vite开启cssCodeSplit: true仅物理拆分CSS为独立文件，但所有CSS仍通过同步link标签插入head并阻塞渲染，并非按需或流式加载。
开启 build.cssCodeSplit: true 后，Vite 会在构建时将不同动态导入（import()）模块中引用的 CSS 拆分为独立文件（如 async-xxx.css），但这些 CSS 文件仍会通过 <link rel="stylesheet"> 同步插入 HTML 的 <head>，**不是流式注入，也不延迟执行**。它不影响 JS chunk 的异步加载逻辑，但会改变样式资源的加载时机和方式。
Link 标签仍是同步插入，不支持流式渲染
Vite 不提供运行时 CSS 流式注入能力。即使组件是异步加载的，其关联的 CSS 文件一旦被识别为该 chunk 的依赖，就会在 chunk 加载完成、执行 JS 前，由 Vite 注入的 runtime 代码同步创建 <link> 并插入 <head>。浏览器收到该标签后立即发起请求并阻塞渲染（render-blocking），直到 CSS 下载、解析完成。
- 这个过程发生在 JS 执行阶段，不是 HTML 解析阶段的流式插入（如
<script type="module">那样的原生流式行为） - 没有
rel="preload"或media="print"等策略干预，默认都是rel="stylesheet" - SSR 场景下更明显：服务端无法预知哪些 CSS 属于后续异步 chunk，容易漏注入或触发 FOUC
异步组件加载流程不受影响，但样式加载不可控
JS 的 import() 动态加载机制照常工作——chunk 下载、执行、挂载组件。但样式部分被“提前绑定”：
- 只要组件文件（如
Dashboard.vue）里有<style>或import './xxx.css'，且该组件是通过import()引入的，对应 CSS 就会被打到同一 chunk，并生成独立.css文件 - 这个 CSS 文件会在 JS chunk 执行前 注入，确保样式就绪；但它不会等到组件真正挂载或用户交互才加载
- 若多个路由组件共用同一份 CSS（比如都 import 了
shared/button.css），该样式可能被重复打包进多个 async chunk，导致体积膨胀
与真正“按需”加载的关键区别
很多人误以为 cssCodeSplit: true = “CSS 按需加载”，其实它只是物理分包，不是逻辑懒加载：
立即学习“前端免费学习笔记（深入）”；
-
静态 import（如入口
main.ts中import './index.css'）→ CSS 进主包，首屏必载 -
动态 import + 组件内样式 → CSS 进对应 async chunk，但仍是同步
<link>插入，非 lazy -
想实现真懒加载：需手动控制，例如用
const link = document.createElement('link')+link.onload = () => mountComponent()，绕过 Vite 默认注入
对首屏性能的实际影响
开启后 Network 面板能看到多个 CSS 文件，但 FCP/LCP 往往无改善，甚至变差：
- HTTP 请求增多（尤其 HTTP/1.1 环境），抵消分包收益
- 多个
<link>并发加载，可能争抢带宽，延迟关键样式到达 - 样式优先级混乱：不同 chunk 的 CSS 加载顺序不确定，
@import或变量覆盖易失效 - 缓存粒度变细，小 CSS 文件更新频繁，CDN 缓存命中率下降
