CSS-in-JS 是组件库开发的刚需，解决样式隔离、主题动态切换、响应式 props 适配及 SSR 一致性等核心问题。
CSS-in-JS 在组件库开发中不是“有优势”，而是解决核心生存问题的刚需——没有它，样式冲突和主题适配几乎无法工程化落地。
组件库必须避免全局类名污染
组件库（比如 Button、Modal）会被成百上千个项目嵌入，一旦用普通 CSS 或 CSS Modules，类名就可能撞上宿主应用的 .button、.modal。即使加前缀，也无法保证不重名，更没法防止宿主通过 !important 或更高权重选择器覆盖。
CSS-in-JS（如 styled-components、emotion）在运行时为每个样式块生成带哈希的唯一类名，例如 sc-bdVaJa 或 css-1x92k6j，天然隔离。这不是“加了作用域”，而是根本没暴露可预测的类名。
- 不依赖构建时命名规则（不像
Button.module.css仍需文件路径参与哈希） - 支持服务端渲染时类名一致性（
emotion的cache配置或styled-components的ServerStyleSheet） - 第三方无法通过 class 名直接 hack 样式，除非显式暴露
classNameprop
主题切换必须靠运行时样式计算
组件库要支持暗色模式、品牌主题、用户自定义配色，就不能靠预编译的 CSS 变量或多套 CSS 文件切换——那样会增大包体积、增加加载延迟、且无法响应 props 变化。
立即学习“前端免费学习笔记（深入）”；
CSS-in-JS 允许你把主题对象直接传进样式函数：
const StyledButton = styled.button`
background-color: ${props => props.theme.colors.primary};
color: ${props => props.variant === 'outline' ? props.theme.colors.primary : 'white'};
`;
这种写法让 theme 和 variant 成为真正受控的输入，React 更新时样式自动重算，无需手动 toggle class 或注入新 style 标签。
- 静态 CSS 变量（
:root { --color-primary: #007bff; }）无法基于 props 动态分支 - CSS-in-JS 库（如
emotion）还支持useThemeHook，在非 styled 组件中复用主题逻辑 - 注意：不要在样式函数里调用未 memo 化的复杂计算，否则每次 render 都触发样式重生成
动态尺寸与响应式需要 JavaScript 运行时判断
组件库常需根据 size、density、isMobile 等 prop 调整 padding、font-size、border-radius。纯 CSS 媒体查询只能处理 viewport，不能响应组件级状态。
例如：
const Card = styled.div`
padding: ${props => props.size === 'sm' ? '8px' : props.size === 'lg' ? '24px' : '16px'};
@media (max-width: 768px) {
padding: ${props => props.size === 'lg' ? '16px' : '8px'};
}
`;
这里混合了 props 分支和媒体查询，CSS-in-JS 会把最终结果编译成带条件的 class，并注入 <style></style> 标签。而传统方案只能靠一堆预设 class（card--size-sm）+ JS 切换，维护成本指数上升。
- 避免在模板字符串里写
if/else，改用三元或提前计算好值，提升可读性 - 响应式断点建议抽成常量（
const MOBILE_BREAKPOINT = '768px';），方便统一管理 - 部分库（如
stitches）支持原子化生成，但组件库通常更倾向语义化样式块，便于调试和设计系统对齐
真正容易被忽略的是：CSS-in-JS 的样式注入时机。如果组件库用 createGlobalStyle 或 Global 注入重置样式，必须确保它在所有组件之前挂载；否则 SSR 时可能出现 FOUC 或服务端/客户端样式不一致。这不是功能问题，而是交付可靠性门槛。
