styled-components能天然避免样式冲突，因其运行时为每个styled组件动态生成唯一哈希类名（如sc-kx8rA），注入<style>标签并绑定到元素，确保样式仅作用于当前组件实例，彻底隔离。
styled-components 为什么能天然避免样式冲突
它不是靠约定或手动加前缀，而是运行时把styled.button生成的样式编译成带哈希的类名（比如css-1a2b3c），再注入到<style>标签里。这个类名只在当前组件实例中生效，哪怕两个不同组件都叫Button，它们的css-xxx也完全不同。
常见错误现象：直接写styled.div`color: red;`却在其他地方看到文字变红——大概率是没清掉旧的全局div { color: red; }规则，或者 SSR 时样式没同步注入。
- 必须用组件方式使用，不能把
styled.button导出后当普通 class 名塞进className - 服务端渲染需配
CacheProvider（emotion）或ServerStyleSheet（styled-components），否则首屏无样式、水合后才闪一下 - 动态插值（如
color: ${props => props.theme.color}）会为每种取值生成新类名，高频变化的 props 容易导致 class 泄漏
emotion 和 styled-components 在类名生成上的关键差异
两者都自动生成哈希类名，但机制不同：emotion默认用css-前缀 + 内容哈希（如css-abc123），而styled-components用sc-前缀 + 组件名哈希（如sc-kx8rA）。前者更轻量，后者调试时略易定位来源。
使用场景影响选择：
立即学习“前端免费学习笔记（深入）”；
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 需要细粒度控制样式缓存或主题切换时，
emotion的css函数 +useTheme组合更灵活 - 偏好“组件即样式”范式、团队已熟悉 React 组件抽象，
styled-components语义更直白 - 若项目已有大量 CSS-in-JS 代码，注意
emotion支持@emotion/react和@emotion/styled双入口，迁移成本更低
:global() 在 CSS-in-JS 中怎么用才安全
CSS-in-JS 默认一切皆局部，但第三方 UI 库（如 Ant Design、Element Plus）的 DOM 结构不可控，有时必须穿透作用域。这时要用:global()，但它不是万能胶——用错就等于主动开个口子让样式逃逸。
典型错误：写styled.div`:global(.ant-btn) { color: blue; }`，结果所有.ant-btn全变蓝。正确做法是限定上下文：
- 只对子元素局部穿透：
styled.div`& :global(.ant-btn) { color: blue; }`（仅作用于该组件内的.ant-btn） - 避免在顶层组件滥用，尤其别在 Layout 或 App 根组件里写
:global(body)这类全局重置 -
:global()内部不能再嵌套伪类或属性选择器，如:global(.btn:hover)可行，但:global(.btn):hover可能不生效
为什么你写了 CSS-in-JS 还有样式污染
最常被忽略的一点：CSS-in-JS 只管自己生成的样式，不管项目里同时存在的其他 CSS 来源。如果你还引入了normalize.css、全局index.css，或者用了import 'antd/dist/reset.css'，这些文件里的规则仍是全局的，照样会污染。
排查顺序建议：
- 打开 DevTools → Elements → 找到目标元素，看哪些样式来自
<style>标签（CSS-in-JS 注入的） vs 哪些来自<link>（外部 CSS 文件） - 检查构建产物中是否有多余的
style标签重复注入（常见于 SSR 多次调用renderToString未清空 cache） - 确认第三方库的样式是否被 Webpack/Vite 当作普通 CSS 处理（应设
rules.exclude避免被 css-loader 处理）
真正起作用的从来不是“用了什么技术”，而是整个样式加载链路有没有被统一收口。哈希类名只是最后一道防线，前面漏了，它也兜不住。
