CSS Modules是解决CSS命名冲突的最佳方案，它在构建阶段将.button编译为Button_button__abc123等唯一哈希类名，物理消除冲突，零JS依赖、无SSR风险；而styled-components依赖运行时生成类名，存在SSR不一致、CSP限制、微前端版本冲突等问题。
styled-components 并不是解决 CSS 命名冲突的“最佳方案”——它只是在特定约束下表现得足够好，但代价是引入运行时依赖和环境限制。
真正能物理消除命名冲突、零 JS 依赖、无 SSR 风险的方案，是 CSS Modules。它在构建阶段就把 .button 编译成类似 Button_button__abc123 的唯一哈希类名，冲突根本不会发生。
为什么 styled-components 的类名不等于“无冲突”？
它的唯一性依赖运行时执行顺序和实例状态：
-
styled-components在浏览器中动态生成<style>标签并注入 DOM，若 JS 报错、被拦截、或未执行完成，样式直接丢失（比如 CSP 策略禁止unsafe-inline） - 服务端渲染时，必须手动用
ServerStyleSheet包裹渲染逻辑，漏配就会触发Warning: Prop `className` did not match - 微前端场景下，多个子应用共用同一
styled-components实例但版本不同，哈希算法可能不一致，导致类名复用甚至样式覆盖 - HMR 热更新时，旧样式规则可能未清除，新旧规则并存造成优先级混乱
CSS Modules 怎么做到“物理消除”冲突？
它不靠 JS 运行时兜底，而是在构建期完成所有类名转换：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 同一个文件里重复定义
.button，会被 css-loader 合并；不同文件里的.button，必然生成不同哈希，完全隔离 - 无需 JS 加载即可生效——静态 HTML 预览、JS 报错 fallback、邮件模板等场景都稳
- 支持
@import、@keyframes、伪类、媒体查询原样透出，不用额外封装函数（对比Emotion的keyframes函数或styled-components的嵌套写法） - 与设计系统对接友好：Ant Design、MUI 等主流 UI 库都提供
.module.css版本，但极少提供完整styled-components封装
什么时候才该选 styled-components？
仅当你的项目满足以下全部条件：
- 纯客户端渲染（CSR），不涉及 SSR / SSG / 邮件模板 / 微前端 strictStyleIsolation
- 团队已统一使用 React + TypeScript + Webpack/Vite，并能规范配置
babel-plugin-styled-components（启用 displayName 和 ssr 支持） - 组件需要高频依赖 props 动态计算样式（如主题色、尺寸响应式），且这些逻辑无法通过 CSS 自定义属性或 class 切换优雅表达
- 接受调试时看到一堆哈希类名（如
sc-fzoLsD），并愿意配合jest-styled-components写快照测试
CSS Modules 解决了第一个，BEM 补足了第二个，而 styled-components 把三者全押在 JS 运行时上——一旦环境稍有偏离，问题就从“命名”升级为“样式不可控”。 
