CSS-in-JS库默认不支持HMR，因其运行时动态注入标签，而HMR仅更新JS模块，未自动清理旧样式，导致重复规则、权重混乱与样式闪动。
为什么CSS-in-JS库默认不支持HMR？
因为多数CSS-in-JS方案（比如 styled-components、@emotion/react）在运行时动态创建 <style></style> 标签并注入样式，而标准Webpack/Vite的HMR只触发JS模块更新，不会自动清理旧的动态样式块。结果就是新样式叠加在旧样式上，出现重复规则、权重混乱、甚至样式“闪动”。
- 开发中改一个
color，浏览器里却看到两套同名class同时生效 -
useEffect里手动插入的<style></style>不会被HMR识别或卸载 - 服务端渲染（SSR）场景下，客户端重 hydration 后样式状态更难对齐
styled-components 怎么开HMR？
必须启用 babel-plugin-styled-components 的 displayName 和 ssr 配置，并配合 styled-components 自带的热更新插件。Vite用户还需额外加 vite-plugin-styled-components。
- Webpack项目：在
.babelrc中确保有{"plugins": ["babel-plugin-styled-components"]} - 启动命令要带
FAST_REFRESH=true环境变量（尤其CRA 4+） - 不要手动调用
StyleSheet.reset()—— 它会清空所有样式，包括第三方UI库的 - 组件必须是命名函数组件（
const Button = styled.button），匿名箭头函数无法被HMR追踪
@emotion/react 的HMR配置要点
@emotion/react 的热重载依赖 @emotion/babel-plugin 插件和 emotion 包内置的 cache 清理机制，但默认只在开发模式下启用。漏掉任何一环都会让HMR静默失效。
Node.js 可靠编程
下载
Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。
- 必须在Babel配置中启用
@emotion/babel-plugin，且sourceMap设为true - 确保
createEmotionCache或CacheProvider没有被封装成全局单例 —— HMR需要每次重新创建cache实例 - 避免在
css模板字符串里写变量计算逻辑（如css`margin: ${x * 2}px`），这类表达式会让HMR无法比对样式变更 - Vite用户需安装
@emotion/react+@emotion/babel-plugin，并确认vite.config.ts中未禁用esbuild.jsxInject
自定义CSS-in-JS方案如何接入HMR？
如果你手写了一个轻量级CSS-in-JS工具（比如基于 CSSStyleSheet.insertRule），HMR就得自己接管样式清理逻辑 —— 没有现成插件兜底。
立即学习“前端免费学习笔记（深入）”；
- 每次模块更新前，用
module.hot.dispose卸载对应<style></style>或清除CSSStyleSheet中的规则 - 给每个动态样式块打唯一ID（比如文件路径+哈希），否则无法精准定位要删哪条
- 注意IE11及以下不支持
CSSStyleSheet.replaceSync，得回退到textContent替换整个标签内容 - 如果用了CSS变量注入（
:root { --color: red }），HMR更新后要手动触发document.documentElement.style.setProperty同步
真正卡住人的往往不是“怎么开”，而是“旧样式没清干净”。HMR只是触发器，样式生命周期管理还得自己兜住。
