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 写静态布局——这看似灵活，实则破坏了样式复用和可维护性：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
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 的耐心。 
