MUI内部样式处理机制及基于MUI搭建设计系统的最优样式方案咨询

MUI 样式实现逻辑说明 #

MUI v5及之后版本底层确实依赖emotion，但做了高度封装，所以你在常规使用中看不到原生emotion语法是正常情况：

• MUI通过@mui/styled-engine层封装了emotion的核心能力，把原生的styled方法、样式生成逻辑都做了内置适配，默认集成了主题变量注入、响应式断点识别、组件样式插槽处理等逻辑，核心组件的样式定义都在内部源码中通过封装后的方法实现，不会对外暴露原生emotion的调用语法。
• 我们日常使用的sx属性、MUI提供的styled工具函数，底层都是走emotion的样式生成逻辑，运行时会把样式转换成CSS类名插入到页面的style标签中。

基于MUI搭建设计系统的最优样式方案 #

对消费侧性能影响最小的方案优先选MUI原生样式方案，其次是CSS Modules，不推荐使用纯inline styles、独立引入styled-components/emotion：

• 沿用MUI原生方案的优势：
  1. 不需要额外引入其他样式依赖，不会出现多套样式运行时共存的问题，打包体积最小。
  2. MUI已经对底层emotion运行时做了大量性能优化，比如全局样式缓存、相同样式类名复用，避免重复生成样式，性能远高于单独引入第三方CSS-in-JS方案。
  3. 如果完全不需要运行时动态修改复杂样式，还可以使用MUI的零运行时静态CSS导出能力，构建时直接生成独立的CSS chunk，完全没有CSS-in-JS的运行时开销，性能和CSS Modules一致，同时还能保持MUI原生的样式书写体验。
• 其他方案的问题：
  • 纯inline styles：性能最差，不仅会导致DOM节点属性臃肿，也无法支持伪类、媒体查询等常规CSS特性，完全不适合用于设计系统。
  • 单独引入styled-components/emotion：会额外引入一套CSS-in-JS运行时，不仅会增大打包体积，还可能和MUI内置的emotion运行时产生冲突，反而会降低消费侧性能。
  • CSS Modules：可以使用，但需要自行处理和MUI主题变量的同步逻辑，维护成本远高于MUI原生方案，性能和MUI零运行时方案基本持平。

如果你的设计系统消费侧对性能要求极高，优先选择MUI的零运行时静态CSS导出方案，既能复用MUI的整套组件能力，也不会带来额外的性能开销。

内容的提问来源于stack exchange，提问作者daniel llach