Emotion 性能问题源于重复计算、缓存失效和 SSR 样式泄漏；需用 useMemo 控制 css 调用、解构 props 避免引用不变、SSR 时统一 cache 并 hydrate 前 reset。
Emotion 本身不慢，性能问题几乎全出在重复计算、缓存失效和 SSR 样式泄漏上——不是写法错，而是没管住 css 调用时机、cache 生命周期和 props 的可序列化性。
为什么每次渲染都新建 css 调用会拖慢页面
css 是纯函数，但每次传新对象（哪怕内容一样）都会触发哈希、序列化、插入 style 标签三连操作。React 严格模式下重渲染两次，就可能生成两份完全相同的 .css-xxx 规则，DevTools 里能看到冗余 style 标签堆叠。
- 错误写法：
const s = css({ color: props.primary ? 'blue' : 'gray' })写在组件函数体内，无useMemo - 正确做法：用
useMemo(() => css({ color: props.primary ? 'blue' : 'gray' }), [props.primary]) - 更轻量替代：用 CSS 自定义属性 + 静态规则，比如
style={{ '--text-color': props.primary ? 'blue' : 'gray' }}配合css({ color: 'var(--text-color)' })
用 styled 时 className 不变但样式没更新，怎么查
styled 组件内部对 props 做浅比较，只在首次调用时生成样式规则；后续 props 引用不变，就不会重算。这不是 bug，是设计使然。
构建 Shopify 嵌入式应用（Embedded App）的开发技能：基于 @shopify/shopify-app-react-router + React Router v7 + Admin API 2026-04。覆盖 shopifyApp 配置、authenticate.admin 的 GraphQL/REST 调用、Webhook 校验、Session 存储、订阅计费、App Bridge 导航、部署，并新增：适用场景判断、安全最佳实践、错误处理与容错、最佳实践、常见问题 FAQ、高级场景。G
- 常见坑：传入
{ theme: { primary: '#007bff' } }这种对象，引用未变 → 样式卡住 - 解法一：解构基础字段，如
primaryColor={theme.primary}，再在模板字符串里用${props => props.primaryColor} - 解法二：复杂推导必须用
useMemo提前提取关键值，再透传，例如const bgColor = useMemo(() => theme.colors.button, [theme.colors.button]) - 别忘了检查是否被
React.memo包裹——它可能拦截 props 更新，导致styled收不到新值
SSR 场景下样式闪屏或重复注入，关键在哪
服务端没收集样式、客户端 hydration 时 cache 不一致，是闪屏和 layout thrashing 的根源。Node 端生成的 HTML 缺少内联样式，客户端就得重跑所有 css 调用，多插 style 标签、多执行 insertRule。
立即学习“前端免费学习笔记（深入）”；
- 服务端必须用唯一
cache实例，并通过CacheProvider注入整棵树 - 必须调用
renderStylesToString或extractCritical捕获样式，把css字符串塞进 - 客户端 hydration 前要调
cache.reset()（仅 SSR 场景），否则服务端注入的规则和客户端新生成的规则可能冲突 - 注意
@emotion/server版本必须与@emotion/react主版本一致，混用会导致缓存 key 错位，内存占用翻倍
真正难的不是写对某一行 css，而是让整个样式生命周期可控：从组件内 useMemo 的依赖项粒度，到服务端 cache 实例的复用，再到全局 global 和 keyframes 的手动清理——漏掉任意一环，内存抖动和样式错乱就藏在下次快速重渲染里。
