Styled Components 并非替代传统 CSS，而是解决组件化中全局污染、命名冲突和状态驱动样式难题；它通过运行时生成唯一类名实现样式隔离，但带来运行时开销、调试复杂度及打包体积增加。
直接说结论：Styled Components 不是用来“替代传统 CSS”的，而是解决传统 CSS 在组件化场景下失控的问题——比如全局污染、命名冲突、状态驱动样式难写。它不是更“高级”，只是换了一种约束条件。
为什么 import './Button.css' 会污染全局作用域
传统 CSS 引入本质是 side effect：Webpack 打包时把 Button.css 里所有规则一股脑注入到 <head>，不管你在哪个组件里 import，.button 就是全局生效的。多个组件都定义 .button？后加载的覆盖前一个，毫无隔离可言。
- 哪怕只在
Button.js里 import，.button依然能被Header.js里的<div class="button">匹配到 - 热更新时，旧 CSS 规则不会自动卸载，容易残留样式
- 无法按需加载：哪怕某个组件没渲染，它的 CSS 也已注入 DOM
styled.button 怎么做到样式不泄漏
它不是往 <head> 插 CSS，而是运行时动态生成唯一类名（如 sc-a1b2c3），再把该类名绑定到对应元素上。关键点在于：每个 styled.xxx 调用都创建新组件，其样式只对该组件实例生效。
- 伪类（
:hover）、媒体查询、嵌套选择器直接写在模板字符串里，无需额外配置 - 支持 props 插值：
background: ${props => props.primary ? '#007bff' : '#6c757d'};，不用拼className - 服务端渲染必须用
ServerStyleSheet或 Next.js 的use client+createGlobalStyle，否则首屏无样式
运行时开销和调试成本在哪
每次组件渲染，styled.button 都会重新执行模板字符串解析、CSS 注入、class 名生成——这不是静态编译，而是 JS 运行时行为。
立即学习“前端免费学习笔记（深入）”；
- 高频重渲染组件（如带动画的
Toast）会放大这部分开销 - 打包体积多出约 14KB gzip（对比纯 CSS Modules），对首屏影响明显
- 开发者工具里看到的是
sc-xxx类名，想定位样式得切到 React DevTools 的 component tab 查 props - TypeScript 下需手动声明模块：
declare module 'styled-components'，否则styled.div返回类型不明确
CSS Modules 和 Styled Components 其实不是对立关系
真实项目里，没人只用一种。基础布局、表单控件、图标这类低交互组件，用 Button.module.css 更轻量；而需要主题切换、状态机控制、复杂过渡的组件（如 Tooltip、ThemeSwitcher），才值得上 styled.div。
容易被忽略的是：二者混用时，CSS Modules 文件里不能用 @import 引入非 .module.css 文件，否则破坏作用域隔离；而 Styled Components 的全局重置（如 createGlobalStyle）必须确保只执行一次，重复调用会导致样式重复注入。
