React企业级项目：SCSS Modules与全局CSS选型最佳实践咨询

核心结论：对电商这类多模块、高迭代频率的企业级项目，组件级SCSS Modules是经过工业界验证的高性价比最佳实践，易用性远高于维护单全局SCSS文件的方案，不存在过高的使用门槛。 #

为什么不建议继续沿用单全局custom.scss的开发模式 #

你之前使用的单全局SCSS写法，仅适配组件量少、迭代频率低的小型站点，放到大型电商项目中会遇到几个无法规避的硬伤：

• 类名冲突风险不可控：电商场景存在大量跨页面复用的通用组件（商品卡、价格标识、操作按钮、营销弹窗等），哪怕严格执行BEM命名规范，项目迭代超过3个月、多团队并行开发时，依然会出现同名样式互相覆盖的问题，排查问题往往需要翻找上千行全局代码
• 样式冗余无法收敛：全局文件中迭代遗留的废弃样式没人敢随意删除，最终打包产物会包含大量当前页面根本用不到的CSS规则，首屏加载的CSS体积会随版本迭代持续膨胀
• 协作冲突成本极高：多开发者同时修改同一个全局SCSS文件，代码合并时的冲突概率会随文件体积增长直线上升，修改某一处业务样式时，需要反复确认不会影响其他不相关的业务模块
• 故障影响范围无法收敛：全局样式的任何修改都是全站生效，很容易出现改了商品详情页的标签样式，结果把个人中心、结算页的同标签类样式带崩的问题

组件级SCSS Modules的实际使用体验 #

你担心的便捷性问题完全不存在，这套方案的学习成本极低，和你现有Sass开发习惯几乎无缝衔接：

• 彻底省去类名命名的心智负担：SCSS Modules会在编译阶段自动将类名转换为带哈希值的唯一标识，比如你在组件内写的.product-price类，编译后会生成类似.product-price__h8d2s的全局唯一类名，从机制上杜绝了样式冲突
• 完全兼容现有Sass能力：你之前用的变量、嵌套、mixin、函数等Sass特性全部可以正常使用，只需要把全局通用的主题变量、重置样式、公共mixin抽成独立的Sass资源文件，在各组件的SCSS文件中通过@use引入即可，不需要重复编写通用逻辑
• 天然支持按需加载：只有组件被实际渲染时，对应的样式才会被加载，打包构建时未被使用的组件样式会被自动tree-shaking移除，同体量项目的首屏CSS体积通常能降到全局方案的30%以下
• 维护定位效率极高：组件样式和组件代码放在同一目录下，找对应样式不需要在全局大文件中全局搜索，修改样式的影响范围被严格限制在当前组件内，不会出现改一处崩全站的问题

落地时的注意事项 #

不需要走极端把所有样式都拆成组件级，合理的搭配方案是「薄全局+厚组件」：

• 全局样式仅保留：CSS重置规则、主题变量定义、全局通用工具类（比如单行省略、flex通用布局类）、原生HTML标签的基础默认样式，这部分内容总体积很小，不会带来维护问题
• 所有和具体业务组件、页面模块强绑定的样式，全部放到对应组件的SCSS Modules文件中
• 跨组件复用的样式逻辑，优先抽成Sass mixin供各组件引入，不要随意新增全局类名

从实际落地经验看，多人协作的中大型电商项目采用这套方案后，样式相关的线上bug占比通常能降到总bug量的5%以内，协作效率比纯全局样式方案提升非常明显。 #

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