next.js 14 app router 默认将所有 css 打包进单个 main.css，需通过 cssbundleid 配合独立 layout.tsx 实现路由级 css 拆分；动态 import css 不被支持，更优策略是精简体积而非强行拆分。
Next.js 14 默认不按路由拆分 CSS，得靠手动干预
Next.js 14 的 App Router 默认将所有 CSS（包括全局样式、CSS Modules、Tailwind 的构建结果）打包进一个 main.css 文件里，无论你有多少个路由或 layout。这会导致用户首次访问任意页面时，都得下载整站样式——哪怕只是看一个极简的 /about 页面。这不是 bug，是默认行为；它牺牲了首屏 CSS 体积换取了构建稳定性和 HMR 一致性。
用 cssBundleId + layout.tsx 实现路由级 CSS 隔离
真正能触发按路由拆分 CSS 的方式，是让不同路由使用完全独立的 layout.tsx，并配合 cssBundleId 强制分离样式块。Next.js 在构建时会把每个带有唯一 cssBundleId 的 layout 视为独立样式上下文。
-
app/(public)/layout.tsx中写：export const cssBundleId = 'public-layout'
-
app/(auth)/layout.tsx中写：export const cssBundleId = 'auth-layout'
-
app/(dashboard)/layout.tsx中写：export const cssBundleId = 'dashboard-layout'
注意：cssBundleId 必须是字符串字面量（不能是变量或函数调用），且每个 layout 文件只能有一个。它不会影响 URL 或运行时行为，只作用于构建阶段的 CSS 分包逻辑。
为什么 import('./SomeComponent.module.css') 不行？
动态 import CSS 模块（比如在客户端组件里用 import('./foo.module.css')）在 Next.js 14 中会被忽略——构建器直接报 warning：Dynamic imports of CSS files are not supported。这是因为 CSS 不是运行时资源，无法像 JS 那样被 dynamic() 加载。试图绕过这个限制（如用 useEffect 插入 <link>）会破坏 SSR 一致性，导致 FOUC 或 hydration mismatch。
- 服务端渲染时没有 DOM，
document.head.appendChild会报错 - 即使加了
typeof window !== 'undefined'判断，样式也只在客户端生效，SEO 和首屏样式不可靠 - 多个路由共用同一份 CSS 变量或重置规则时，手动加载顺序极易出错
更现实的优化路径：别拆 CSS，先压体积
与其花精力硬拆 CSS，不如优先解决真正拖慢首屏的根源：
- 确保
tailwind.config.ts启用了content路径扫描，避免未使用的工具类打入生产包 - 禁用
@layer base里冗余的全局重置（比如重复引入 normalize.css + modern-normalize） - 把大图标字体（如 Font Awesome）换成
next/font或 SVG 内联，避免额外 CSS + 字体请求 - 检查
app/globals.css是否悄悄 import 了第三方 UI 库全量样式（如import 'antd/dist/reset.css'）
实际项目中，一个合理配置的 Tailwind + 自定义组件的 CSS 总体积通常在 20–40 KB（gzip 后），远低于 JS bundle。强行按路由拆分反而可能因重复基础样式（如 reset、flex 工具类）导致总和更大。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
