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

在 Next.js 项目中选择 CSS-in-JS 方案时，许多开发者第一反应是 styled-components 或 emotion。但若论及哪个方案最省心、最不容易踩坑，答案其实很明确：styled-jsx。它开箱即用，原生支持服务端渲染（SSR）和静态生成，构建时自动将样式提取为静态 标签并注入 HTML，运行时零开销。默认采用局部作用域，类名自动哈希，无需额外配置。相比之下，styled-components 等功能更丰富的方案，必须手动处理 ServerStyleSheet、Babel 插件和 ThemeProvider 包裹，否则服务端渲染时容易遗漏样式，甚至触发 hydration mismatch 错误。

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

Next.js 在构建阶段会将 styled-jsx 中的样式提取为静态 标签，直接注入 HTML。服务端渲染时你写什么样式，浏览器就能拿到什么，客户端无需二次计算或重新挂载样式。这实现了真正的“一次编译，到处运行”。

• 无需安装 Babel 插件（如 babel-plugin-styled-components）
• 无需配置 Webpack loader（省去 css-loader、style-loader）
• 伪类、媒体查询、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 中才能生效
• 同一个组件中混用内联样式和 class，DOM 上同时出现两种来源，调试时难以定位问题
• 服务端渲染时，style 中的 JS 表达式（如 {color: theme.primary}）若未预计算，可能变成空对象或 undefined

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

很多人认为 CSS-in-JS 慢是因为“JS 执行慢”，但真正的瓶颈在于样式规则的重复生成和注入逻辑拖慢了首次渲染：

• styled-components 每次组件挂载都会检查是否已注入对应的 hash 类名——服务端已注入的样式，客户端又重复执行，浪费 CPU 资源
• emotion 的 css 函数在严格模式下会进行额外的 source map 校验，导致开发环境明显变卡
• styled-jsx 由于构建时静态编译，运行时零开销，但缺点是不支持运行时主题切换（需借助 CSS 变量 + :root 动态修改）

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