CSS-in-JS适合中后台项目吗，为什么容易失控？

CSS-in-JS在中后台项目中易失控，根源在于组件粒度混乱、主题扩散无约束、SSR类名不一致；需限定仅业务组件用css函数、基础组件用CSS Modules、主题交由CSS变量管理、SSR统一cache并预提样式。

CSS-in-JS 在中后台项目里不是“不适合”，而是极易在缺乏约束时快速失控——失控点不在语法，而在组件粒度、主题扩散和 SSR 一致性这三处。

中后台项目里 CSS-in-JS 的失控源头是组件复用与样式耦合

中后台系统大量使用可配置的通用组件（如 Table、Form.Item、Card），这些组件常被跨模块、跨包复用。一旦每个使用方都用 styled.xxx 或 css 函数重写一遍样式，就会出现：

1. 同一逻辑组件在不同页面生成不同 hash 类名（比如 sc-abc123 和 sc-def456），导致无法通过 class 名统一覆盖或调试
2. 样式逻辑散落在各处：主题色从 props 传入、尺寸从 context 拿、禁用态逻辑重复写三次，没有中心化入口
3. 构建产物中同一样式规则被多次序列化注入，<style> 标签数量随路由增加线性增长，而非收敛

主题切换场景下，CSS-in-JS 容易变成状态管理灾难

中后台几乎必有暗黑模式、多租户主题、A/B 测试等需求。但多数 CSS-in-JS 库默认把主题值作为 props 直接参与样式计算，这就带来连锁问题：

1. 每次主题变更，所有带插值的组件都会触发重渲染（哪怕 UI 没变），因为 props.theme 是新对象引用
2. 用 css({ color: theme.primary }) 这类写法，若 theme 对象未 memo 化，哈希缓存失效，样式重复插入
3. 服务端渲染时，若主题 token 来自请求上下文（如 cookie 或 header），而客户端 hydration 时取的是 localStorage，默认不一致 → 类名 mismatch 错误

SSR + CSR 混合场景下，hash 不稳定是静默崩溃点

中后台项目普遍启用 SSR（Next.js / Nuxt / Rspack SSR），但 CSS-in-JS 的类名稳定性极度依赖构建时配置：

1. 未启用 @emotion/babel-plugin 或 babel-plugin-styled-components → 服务端生成的类名基于 AST，客户端基于运行时字符串，必然 mismatch
2. 多个子包各自安装不同版本的 @emotion/cache → 各自维护独立 cache 实例，同一段样式被插入多次，且顺序不可控
3. 动态 import 组件中使用 styled → chunk 加载时机不确定，<style> 标签插入顺序错乱，导致优先级覆盖失效（比如 Button 的 hover 样式盖不住 Modal 的 backdrop）

真正可控的做法，不是禁用 CSS-in-JS，而是把它锁死在「有限动态」范围内：只允许在业务组件（非基础组件）中用 css 函数封装原子样式，基础组件一律用 CSS Modules；主题变量必须走 CSS 自定义属性（var(--color-primary)）透出，JS 层只做开关，不做计算；所有 SSR 入口强制统一 cache 实例并预提取样式。