能，但只解决“时机”问题，不是性能银弹。它让样式在 DOM diff 完成后、真实 DOM 修改前注入，避免了 useLayoutEffect 强制重排和 useEffect 延迟导致的布局跳动；需配合稳定 hash 缓存 style 标签、复用 sheet.insertRule、禁止读取 DOM 等措施才有效。
useInsertionEffect 能解决高频渲染下的样式抖动吗？
能，但只解决“时机”问题，不是性能银弹。它让样式在 DOM diff 完成后、真实 DOM 修改前注入，避免了 useLayoutEffect 强制重排和 useEffect 延迟导致的布局跳动。但如果你每次渲染都新建 <style> 标签或重复调用 sheet.insertRule()，反而加剧内存分配和 DOM 操作压力。
必须配合以下做法才有效：
- 基于 props 或主题生成稳定 hash（如
css-${hash(props)}），命中缓存就跳过创建 - 复用已有
<style>标签，只用sheet.insertRule()追加规则，而非重写textContent - 禁止在
useInsertionEffect里读取 DOM（如getBoundingClientRect()），否则会触发 React 警告
Emotion 为什么有时比传统 CSS 还慢？
Emotion 的性能红利依赖三个前提：SSR 提取、cache 复用、Babel 静态编译。一旦任一环节断裂，就会退化为纯运行时样式计算。
常见掉坑场景：
立即学习“前端免费学习笔记（深入）”；
- 组件内每次渲染都传入新对象：如
css({ fontSize: `${props.size}px` })→ 破坏哈希缓存，重复序列化 - 未启用
@emotion/babel-plugin→ 静态样式被迫推到运行时生成 - 多个包安装不同版本
@emotion/cache→ cache 实例不共享，同一规则被多次插入 - 在
useEffect中动态调用css→ 绕过 Emotion 的序列化路径，失去哈希去重能力
Linaria 的 zero-runtime 模式真的零开销吗？
不是自动生效的。Linaria 默认仍带轻量 runtime，用于 dev 热更新和 fallback；必须显式配置才能关闭 JS 注入逻辑。
关键检查点：
- Webpack：确认
linaria/loader配置含{ rules: [{ action: 'ignore' }] }，且未引入@linaria/react - Vite：
vite.config.ts中需设dev: false并禁用 hot 相关插件 - 构建产物中不能出现
insertRule、style.textContent =或createTextNode调用 - 动态表达式（如
props.theme === 'dark' ? '#000' : '#fff'）会让整块样式 fallback 到 runtime
Ant Design 5.0 的 Hash 策略为什么更稳？
它把哈希粒度从「样式内容」降到「环境」，只依赖包版本和主题 token，而不是每个组件的 props。这样 80% 的样式计算变成一次性的，组件复用、重渲染都不再触发重复序列化。
这种设计对大型项目特别关键：
- 主题切换时，只需清空主题级缓存，而非逐个组件重算
- 同一主题下，所有 Button、Input 的样式哈希完全一致，天然去重
- 避免了因 props 微小变化（如
key、id）导致的无效哈希变更
真正卡住性能的，从来不是“用了 CSS-in-JS”，而是没管住哈希稳定性、缓存边界和构建链路的确定性。这些细节在小项目里藏得住，在大型项目里全是显性瓶颈。
