如何在Next.js项目中使用CSS-in-JS提升开发效率

styled-jsx 是最省心的选择，因其开箱即用、天然支持 SSR/静态生成、构建时提取样式、零运行时开销，且默认局部作用域、无需额外配置；而 styled-components 等需手动处理 ServerStyleSheet、Babel 插件和 ThemeProvider 包裹，否则易出 hydration mismatch。

styled-jsx 是 Next.js 原生支持的 CSS-in-JS 方案，开箱即用，不需要额外安装或配置。其他方案如 styled-components 或 emotion 虽然功能更丰富，但必须手动配 HMR、SSR 和构建插件，否则在服务端渲染时会漏样式或触发 hydration mismatch 错误。

为什么 styled-jsx 是最省心的选择

Next.js 在构建阶段就将 styled-jsx 样式提取为静态 <style> 标签并注入 HTML，天然支持 SSR 和静态生成。你写什么，服务端就吐什么，客户端不会二次计算或重挂样式。

• 无需 Babel 插件（babel-plugin-styled-components 等）
• 不依赖 Webpack loader 配置（css-loader、style-loader）
• 伪类（:hover）、媒体查询（@media）、CSS 变量都能直接写
• 局部作用域默认开启，类名自动哈希，避免冲突

styled-components 在 Next.js 中必须处理的三个关键点

如果你坚持用 styled-components，以下三点不解决，开发阶段就会报错或样式丢失：

• _document.tsx 里必须用 ServerStyleSheet 捕获服务端样式，并通过 getInitialProps 注入到 HTML；漏掉这步，首屏无样式
• 开发时需启用 babel-plugin-styled-components 并设 ssr: true，否则热更新后样式失效
• 全局主题（ThemeProvider）必须包裹在 app/layout.tsx 或 pages/_app.tsx 的最外层，且不能跨路由重新挂载

内联样式 + className 混用时的常见陷阱

很多人想用 style 属性控制动态颜色，再用 styled-jsx 写静态布局——这看似灵活，实则破坏了样式复用和可维护性：

• style 属性无法响应伪类或动画，transition 必须写在 styled-jsx 里才生效
• 同一组件中混合使用，会导致 DOM 上同时存在内联 style 和 class，调试时难以定位来源
• 服务端渲染时，style 中的 JS 表达式（如 {color: theme.primary}）若未被预计算，会变成空对象或 undefined

性能敏感场景下，CSS-in-JS 的真实开销在哪

不是“JS 执行慢”，而是样式规则的重复生成和注入逻辑拖慢首次渲染：

立即学习“前端免费学习笔记（深入）”；

• styled-components 每次组件 mount 都会检查是否已注入对应 hash 类名，服务端已注入的，在客户端又走一遍，浪费 CPU
• emotion 的 css 函数在严格模式下会做额外的 source map 校验，开发环境明显变卡
• styled-jsx 因为构建时静态编译，运行时零开销，但不支持运行时主题切换（得靠 CSS 变量 + :root 动态改）

真正需要动态主题或复杂样式逻辑时，styled-components 或 emotion 才值得投入配置成本；日常组件封装，styled-jsx 就是那个“写了就跑，不用想”的答案。别低估构建时确定性的价值——它省下的不只是配置时间，还有半夜排查 hydration error 的耐心。