生产环境CSS-in-JS类名不稳定是构建配置与运行时注入脱节所致，非库本身问题；需检查哈希是否启用contenthash、SSR水合是否共享cache、Babel插件是否污染生产构建、主题对象是否纯JSON可序列化。
生产环境出现CSS-in-JS类名不稳定，基本是构建时哈希生成逻辑被干扰或未对齐导致的——不是库本身问题，而是构建配置与运行时注入机制脱节。
检查 Emotion / Styled Components 的哈希生成是否启用 contenthash
Emotion 和 Styled Components 在生产模式下默认依赖 contenthash 生成稳定类名，但这个行为会被以下情况破坏：
- Webpack 配置中
css-loader的modules.localIdentName被显式覆盖，且未区分环境（例如写死为[name]__[local]--[hash:base64:5]） - 使用了
style-loader而非mini-css-extract-plugin—— 前者在生产环境不支持contenthash，会退化为路径哈希 - 源码中存在动态插值（如
css\`color: \${theme.color}\`），导致样式无法被静态分析，哈希依据丢失
验证方式：构建后查看生成的 CSS 文件，搜索类名是否含一致哈希（如 sc-kXGQHM 或 css-1a2b3c）；若每次构建都变，说明哈希未绑定内容。
确认 SSR 水合阶段的 class 名一致性
服务端渲染（SSR）和客户端水合（hydration）必须使用完全相同的哈希种子，否则会出现样式闪烁或失效：
立即学习“前端免费学习笔记（深入）”；
- Next.js 或 Remix 中，确保
emotion-server或@emotion/react的CacheProvider在服务端与客户端共享同一key和insertionPoint - 避免在服务端用
createCache({ key: 'css' })，客户端却用默认 cache —— 必须显式传入相同key - 检查是否在
getServerSideProps或generateStaticParams中误调用了组件（触发服务端执行但未走 SSR 流程），导致服务端生成的类名与客户端不匹配
典型错误现象：Warning: Prop `className` did not match. + 页面初始渲染无样式，几毫秒后才恢复。
禁用开发模式下的随机哈希干扰生产配置
很多项目在开发环境为了调试启用了 babel-plugin-emotion 或 styled-components/babel 的 fileName、displayName 等选项，这些插件若未按环境开关，会污染生产构建：
- Emotion：检查
.babelrc是否对production环境关闭了sourceMap和autoLabel（它们会引入文件路径依赖，破坏哈希稳定性） - Styled Components：确认
stylis-plugin-rtl或自定义 stylis 插件未在生产环境注入运行时逻辑（如基于document判断方向），这会导致服务端/客户端结果不一致 - Vite 用户需检查
vite.config.ts中是否对build.cssCodeSplit或build.rollupOptions.output.manualChunks做了不当拆分，导致样式 cache 分片错乱
一个快速验证点：临时删掉所有 Babel 插件，仅保留基础 preset，重新构建看类名是否稳定。
避免主题 Provider 中的动态计算干扰哈希
如果使用 ThemeProvider 并在 theme 对象中嵌入函数（如 fontSize: (scale) => \`calc(1rem * \${scale})\`），CSS-in-JS 库可能在构建时无法序列化该值，转而用 Math.random() 或时间戳生成 fallback 类名：
- 主题对象必须是纯 JSON 可序列化的（即只含字符串、数字、布尔、null、数组、嵌套对象）
- 函数式值应移至组件内联逻辑，而非塞进 theme；或者用
useTheme+css函数动态生成，不参与构建期哈希 - Emotion v11+ 支持
cache.compat模式，但开启后会禁用部分哈希优化，不建议用于生产
最容易被忽略的是：本地开发时主题从 localStorage 读取深色模式，但服务端没有该值，导致 theme 差异直接引发类名分裂 —— 这类逻辑必须收口到客户端专属 hook 中。
