Next.js全局导入SCSS及迁移CSS Modules的性能问题咨询

全局导入SCSS是否会降低性能？ #

要分场景判断，没有绝对的答案：

• 开发环境下的性能损耗是明确可感知的：所有样式全量在_app.js顶层导入的话，每次修改任意一处SCSS代码，热更新流程都会重新编译整个SCSS依赖树，项目体量越大（比如拆分了上百个SCSS分片、组件样式全挂在全局），热更新等待时间越长。
• 生产环境下不会产生夸张的运行时性能损耗，但存在两个隐性成本：
  1. 首屏会加载全量CSS包，哪怕用户访问的页面根本用不到其中大部分样式，CSS体积过大会直接阻塞渲染，拖慢FCP、LCP这类核心性能指标；
  2. 全局样式没有作用域隔离，为了避免类名冲突，开发者往往会写更深的选择器嵌套、更长的类名，冗余的选择器规则既会增加CSS体积，也会小幅提升浏览器样式计算的开销，还很容易残留没被用到的死代码。

是否需要改为组件内以CSS Modules形式导入？ #

不用一刀切全量迁移，根据项目规模判断即可：

• 如果是小型项目，全局SCSS总代码量只有几百行，内容以CSS重置、主题变量、全局通用工具类为主，完全没必要硬改，当前写法的维护成本和性能损耗都可以忽略。
• 如果是中大型项目，组件数量多、不同路由页面的样式差异大，非常建议迁移，除了性能收益外，CSS Modules天然的作用域隔离可以彻底解决类名冲突问题，不用再手动维护BEM这类命名规范，长期维护成本低很多。

迁移到CSS Modules能否带来显著性能收益？ #

收益是明确的，但是否“显著”取决于原有全局样式的冗余程度：

• 首屏加载层面：Next.js原生支持CSS Modules的代码分割，生产构建时会自动把样式和对应的组件/路由绑定，用户访问对应页面时才会加载所需的CSS，首屏CSS体积会有明显下降，弱网环境下的性能提升感知非常强。
• 开发效率层面：单个组件的样式修改只会触发对应模块的重新编译，热更新速度比全量全局编译快很多，大项目下开发体验提升很明显。
• 要注意：全局的CSS重置、主题变量、通用原子类本来就是要全站生效的，这部分完全可以保留全局导入的方式，不用强行塞进CSS Modules，避免无意义的重复代码。如果SCSS里需要用到全局变量、mixin，可以直接在Next.js配置里做全局注入，不用每个模块文件单独引入。

补充一个常见误区：全局导入和CSS Modules的运行时样式计算开销差异极小，除非你原来的全局样式写了极深的嵌套、大量通配符选择器，否则用户实际交互时几乎感知不到这部分的差异，性能收益主要来自构建速度提升和首屏CSS体积优化。

内容的提问来源于stack exchange，提问作者DanielDev-ine