应关闭 cssCodeSplit: false，因其可避免 FOUC、减少重复 CSS、提升缓存效率；关闭后所有 CSS 合并为 style.css 并注入 head，更可控。
默认开启的 cssCodeSplit: true 很可能正在拖慢你的首屏加载，且让 CSS 缓存变得不可控——除非你明确需要按路由/主题动态加载样式，否则应优先设为 false。
什么时候必须关掉 cssCodeSplit
绝大多数中后台项目、SSR 应用、或使用了 @import / layer 等级联规则的样式体系，都不该依赖自动 CSS 分割：
- 开启后，Rollup 会把每个
import './xxx.css'拆成独立 chunk，导致样式加载时机不可预测，容易触发 FOUC（闪白） - 多个 chunk 中重复引入同一套 reset 或变量，反而增大总 CSS 体积
- 浏览器无法对零散的
.css文件做有效缓存复用，vendor.css和index.css的更新耦合被破坏 -
build.rollupOptions.output.manualChunks对 CSS 完全无效，除非cssCodeSplit: true，但此时 manualChunks 只能干预 JS chunk 的归属，不能合并 CSS
cssCodeSplit: false 后，CSS 去哪了？
关闭后，所有非内联样式（包括 import、@import、组件 <style>）会被收集进一个统一的 style.css（实际名由 assetFileNames 决定），并注入 HTML 的 <head>。这不是“退化”，而是回归可控：
- 你可以用
build.rollupOptions.output.assetFileNames把它固定为[name].[hash].css，确保长期缓存 - 配合
build.rollupOptions.output.manualChunks把 JS vendor 单独拆出，CSS 就自然只随业务代码变动 - 若需主题切换，改用 JS 动态
document.head.appendChild(link)加载theme-dark.css，而非依赖构建时分割
真要开 cssCodeSplit: true，必须满足这四条
不是“可以开”，而是“不满足以下全部条件就别开”：
立即学习“前端免费学习笔记（深入）”；
- 项目已通过 JS 显式控制主题切换，且
theme-dark.css和theme-light.css是完全隔离、互斥加载的 - 第三方 UI 库（如 Ant Design）的样式是懒加载的，例如
import('antd/dist/reset.css')，而非在入口main.ts中静态import - 微前端基座强制要求每个子应用的 CSS 必须按路由 chunk 隔离（常见于 legacy 基座）
- 你已用
build.rollupOptions.output.manualChunks函数精确声明了哪些模块归入哪个 CSS chunk，并验证过加载顺序不会导致样式覆盖失效
manualChunks 对 CSS 实际起什么作用？
它本身不处理 CSS，但它决定了 JS chunk 的边界，间接影响 CSS 归属：
-
cssCodeSplit: false→ 所有 CSS 合并进单个文件，manualChunks仅影响 JS -
cssCodeSplit: true→ Rollup 先按拓扑关系生成 CSS chunk，再用manualChunks函数尝试将匹配的 JS 模块归组；只有当某 JS chunk 被manualChunks单独拎出，且它 import 了唯一一份 CSS，那份 CSS 才可能被绑定到该 chunk - 换句话说：
manualChunks是“JS 分组指令”，CSS 只是附带产物；想控制 CSS，得先控制 JS 的 import 关系和 chunk 边界
最常被忽略的一点：CSS 分割的粒度最终取决于你代码里 import 的位置和方式，而不是配置开关本身。删掉一个 import './Button.css'，比调十次 cssCodeSplit 更管用。
