卡顿主因是styled-components在高频挂载/卸载时动态增删@keyframes触发CSSOM重解析，导致合成线程受阻；最优解是改用外部CSS文件定义keyframes并以class控制动画。
卡顿不是 Styled Components 本身写动画的能力差，而是它在高频挂载/卸载场景下反复操作 @keyframes 规则，触发浏览器 CSSOM 重解析 —— 这个过程在低端 Android 或长列表滚动中会明显拖慢合成线程。
styled-components 的 keyframes 注入机制会动态增删样式表
每次调用 keyframes 函数，它都会生成新哈希名，并通过 document.styleSheets.insertRule() 插入一条规则；组件卸载时再调用 deleteRule() 删除。这不是一次性注册，而是随生命周期反复执行：
- 列表项使用带动画的
Box组件，滚动时频繁 mount/unmount → 规则被快速增删 - 路由切换带入场动画的页面 → 多个
keyframes同时注入又清理 - SSR 水合阶段，服务端已注入规则，客户端又重复插入 → 样式表状态不一致
浏览器对 insertRule 和 deleteRule 的调用并不轻量，尤其在 Chrome 85–95 的 WebView 中，单次操作可能引发微卡顿。
静态样式和动态样式混写会让缓存失效
Styled Components v5+ 对纯静态样式（不含 ${props => ...}）做了优化，只注入一次；但只要样式里混入任意插值表达式，整个规则就会失去缓存能力，每次渲染都重新计算类名、生成新规则：
-
const Button = styled.button`padding: 8px; color: ${props => props.theme.primary};`→ 动态部分污染全部，无法复用 - 哪怕只有颜色变化，也会导致 transform 动画相关的 class 名全变，浏览器丢掉旧图层、重建新图层
- React 18 并发渲染下，样式计算可能被中断重试多次，进一步放大开销
移动端卡顿常被误判为“动画问题”，实则是图层管理失控
加了 will-change: transform 却更卡？大概率是因为 Styled Components 导致元素频繁销毁重建，让浏览器不断创建/回收合成图层：
- 每个新注入的
@keyframes名对应一个新动画名，旧动画实例未清理干净，图层残留 - 列表项用
keyframes做入场动画，一屏 20 个 → 浏览器尝试维持 20 个独立 GPU 图层 - 低端设备内存吃紧，触发图层降级或 WebView 回收，直接白屏或掉帧
真正要盯住的不是动画写法，而是 DevTools Layers 面板里有没有意外的图层爆炸，以及 Memory 面板中 HTMLStyleElement 实例数是否随滚动线性增长。
最稳妥的解法不是调参数或换库，而是把动画逻辑从组件生命周期里摘出来：用外部 CSS 文件定义 @keyframes，用 class 控制触发，彻底绕过运行时样式注入 —— 这一步省掉的不是 JS 计算，是浏览器 CSSOM 的整轮重解析。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
