CSS-in-JS在中后台项目中易失控，根源在于组件粒度混乱、主题扩散无约束、SSR类名不一致；需限定仅业务组件用css函数、基础组件用CSS Modules、主题交由CSS变量管理、SSR统一cache并预提样式。
CSS-in-JS 在中后台项目里不是“不适合”，而是极易在缺乏约束时快速失控——失控点不在语法，而在组件粒度、主题扩散和 SSR 一致性这三处。
中后台项目里 CSS-in-JS 的失控源头是组件复用与样式耦合
中后台系统大量使用可配置的通用组件（如 Table、Form.Item、Card），这些组件常被跨模块、跨包复用。一旦每个使用方都用 styled.xxx 或 css 函数重写一遍样式，就会出现：
- 同一逻辑组件在不同页面生成不同 hash 类名（比如
sc-abc123和sc-def456），导致无法通过 class 名统一覆盖或调试 - 样式逻辑散落在各处：主题色从 props 传入、尺寸从 context 拿、禁用态逻辑重复写三次，没有中心化入口
- 构建产物中同一样式规则被多次序列化注入，
<style>标签数量随路由增加线性增长，而非收敛
主题切换场景下，CSS-in-JS 容易变成状态管理灾难
中后台几乎必有暗黑模式、多租户主题、A/B 测试等需求。但多数 CSS-in-JS 库默认把主题值作为 props 直接参与样式计算，这就带来连锁问题：
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 每次主题变更，所有带插值的组件都会触发重渲染（哪怕 UI 没变），因为
props.theme是新对象引用 - 用
css({ color: theme.primary })这类写法，若theme对象未 memo 化，哈希缓存失效，样式重复插入 - 服务端渲染时，若主题 token 来自请求上下文（如 cookie 或 header），而客户端 hydration 时取的是 localStorage，默认不一致 → 类名 mismatch 错误
SSR + CSR 混合场景下，hash 不稳定是静默崩溃点
中后台项目普遍启用 SSR（Next.js / Nuxt / Rspack SSR），但 CSS-in-JS 的类名稳定性极度依赖构建时配置：
立即学习“前端免费学习笔记（深入）”；
- 未启用
@emotion/babel-plugin或babel-plugin-styled-components→ 服务端生成的类名基于 AST，客户端基于运行时字符串，必然 mismatch - 多个子包各自安装不同版本的
@emotion/cache→ 各自维护独立 cache 实例，同一段样式被插入多次，且顺序不可控 - 动态 import 组件中使用
styled→ chunk 加载时机不确定，<style>标签插入顺序错乱，导致优先级覆盖失效（比如Button的 hover 样式盖不住Modal的 backdrop）
真正可控的做法，不是禁用 CSS-in-JS，而是把它锁死在「有限动态」范围内：只允许在业务组件（非基础组件）中用 css 函数封装原子样式，基础组件一律用 CSS Modules；主题变量必须走 CSS 自定义属性（var(--color-primary)）透出，JS 层只做开关，不做计算；所有 SSR 入口强制统一 cache 实例并预提取样式。
