CSS 模块化架构的演进BEM、CSS Modules 到 CSS-in-JS 的反思一、引子那个 BEM 类名比内容还长的组件翻到五年前写的代码一个按钮的 class 是header__nav--primary-btn__label--is-active。它在 2019 年是正确的——BEM 方法论是当时应对CSS 全局作用域问题的最佳实践。但站在 2026 年回头看这条演进路径上有太多当时看起来正确后来发现代价很大的决策。CSS 模块化的演进是一场作用域控制 vs 表达能力 vs 性能的三角博弈。每一代方案都在优化其中两个维度代价是牺牲第三个。二、先把评价标准说清楚选样式方案时别只比较写一段按钮样式要几行代码。至少要看四件事样式能否被安全删除、主题变量是否能统一管理、服务端渲染是否稳定以及新人能否在不阅读整套约定的情况下修改一个组件。团队若主要维护长期产品最后两项通常比“首次开发速度”更重要。也不要把 BEM、CSS Modules 和 CSS-in-JS 当作互斥阵营。一个项目可以用 CSS Modules 处理业务组件用少量全局 CSS 放 Token 和 reset已有的 CSS-in-JS 组件也不必为了风格统一而一次性重写。先约束新增代码再在改动旧页面时顺手迁移成本更可控。三、各方案的适用场景与问题BEM适合项目初期维护成本随规模增长BEM 的核心思想是用命名约定模拟作用域。block__element--modifier的命名模式提供了人工可读的作用域信息。问题是它依赖开发者自律——哪天有人写了.header .btn而不是.header__btn没有编译器会报错。适用简单网站、不需要组件化的小项目。CSS Modules2026 年仍然是最佳平衡点CSS Modules 在编译时对类名进行哈希处理确保每个组件的样式被隔离到唯一的类名空间。它保留了完整的 CSS 表达能力不像 CSS-in-JS 限制某些选择器且没有运行时性能开销所有处理在构建时完成。/* Button.module.css */ .button { /* 编译后: .Button_button_abc123 */ composes: base from ./base.module.css; padding: var(--spacing-md); }适用绝大多数 Web 应用。配合 CSS 自定义属性Token和layer管理优先级。CSS-in-JS运行时成本被低估了Styled Components 和 Emotion 在 2020-2024 年间非常流行。它们的优势是样式和逻辑在一起的 colocation 理念和动态样式的便利性。但运行时成本是一个严重问题每个样式对象需要序列化 → 注入style标签SSR 时样式需要额外处理提取关键 CSS包体积增加 12-15KBgzip在 React 18 并发模式下有兼容性问题2025 年开始社区明显在回归编译时方案零运行时 CSS-in-JS 如 Panda CSS、Vanilla Extract或回归 CSS Modules。四、2026 年的推荐架构CSS 架构 CSS Modules CSS Custom Properties layer - CSS Modules组件级作用域隔离 - CSS Custom Properties设计 Token 主题切换 - layer优先级管理reset → base → components → utilities五、迁移建议从全局 CSS 或 BEM 迁移时先找样式冲突最多、改动最频繁的页面作为试点。把公共颜色和间距提取为变量再迁移组件本身不要先批量改类名。每迁移一个页面用视觉回归截图比对桌面和移动端并检查键盘焦点、禁用态和高对比度主题。这样能把“样式重构”变成可回滚的小批次而不是一次难以验证的改造。六、结论CSS 模块化经历了 BEM命名约定→ CSS Modules编译时→ CSS-in-JS运行时→ 回归编译时四个阶段2026 年最佳平衡点是 CSS Modules CSS 自定义属性 layerCSS-in-JS 的运行时成本SSR 性能、包体积是回归编译时方案的主因BEM 在简单项目中仍然可用但缺乏编译器级别的安全保障零运行时 CSS-in-JSPanda CSS, Vanilla Extract是兼顾 colocation 和性能的折中方案选择方案时优先看维护方式和渲染路径不要只看语法偏好
CSS 模块化架构的演进BEM、CSS Modules 到 CSS-in-JS 的反思一、引子那个 BEM 类名比内容还长的组件翻到五年前写的代码一个按钮的 class 是header__nav--primary-btn__label--is-active。它在 2019 年是正确的——BEM 方法论是当时应对CSS 全局作用域问题的最佳实践。但站在 2026 年回头看这条演进路径上有太多当时看起来正确后来发现代价很大的决策。CSS 模块化的演进是一场作用域控制 vs 表达能力 vs 性能的三角博弈。每一代方案都在优化其中两个维度代价是牺牲第三个。二、先把评价标准说清楚选样式方案时别只比较写一段按钮样式要几行代码。至少要看四件事样式能否被安全删除、主题变量是否能统一管理、服务端渲染是否稳定以及新人能否在不阅读整套约定的情况下修改一个组件。团队若主要维护长期产品最后两项通常比“首次开发速度”更重要。也不要把 BEM、CSS Modules 和 CSS-in-JS 当作互斥阵营。一个项目可以用 CSS Modules 处理业务组件用少量全局 CSS 放 Token 和 reset已有的 CSS-in-JS 组件也不必为了风格统一而一次性重写。先约束新增代码再在改动旧页面时顺手迁移成本更可控。三、各方案的适用场景与问题BEM适合项目初期维护成本随规模增长BEM 的核心思想是用命名约定模拟作用域。block__element--modifier的命名模式提供了人工可读的作用域信息。问题是它依赖开发者自律——哪天有人写了.header .btn而不是.header__btn没有编译器会报错。适用简单网站、不需要组件化的小项目。CSS Modules2026 年仍然是最佳平衡点CSS Modules 在编译时对类名进行哈希处理确保每个组件的样式被隔离到唯一的类名空间。它保留了完整的 CSS 表达能力不像 CSS-in-JS 限制某些选择器且没有运行时性能开销所有处理在构建时完成。/* Button.module.css */ .button { /* 编译后: .Button_button_abc123 */ composes: base from ./base.module.css; padding: var(--spacing-md); }适用绝大多数 Web 应用。配合 CSS 自定义属性Token和layer管理优先级。CSS-in-JS运行时成本被低估了Styled Components 和 Emotion 在 2020-2024 年间非常流行。它们的优势是样式和逻辑在一起的 colocation 理念和动态样式的便利性。但运行时成本是一个严重问题每个样式对象需要序列化 → 注入style标签SSR 时样式需要额外处理提取关键 CSS包体积增加 12-15KBgzip在 React 18 并发模式下有兼容性问题2025 年开始社区明显在回归编译时方案零运行时 CSS-in-JS 如 Panda CSS、Vanilla Extract或回归 CSS Modules。四、2026 年的推荐架构CSS 架构 CSS Modules CSS Custom Properties layer - CSS Modules组件级作用域隔离 - CSS Custom Properties设计 Token 主题切换 - layer优先级管理reset → base → components → utilities五、迁移建议从全局 CSS 或 BEM 迁移时先找样式冲突最多、改动最频繁的页面作为试点。把公共颜色和间距提取为变量再迁移组件本身不要先批量改类名。每迁移一个页面用视觉回归截图比对桌面和移动端并检查键盘焦点、禁用态和高对比度主题。这样能把“样式重构”变成可回滚的小批次而不是一次难以验证的改造。六、结论CSS 模块化经历了 BEM命名约定→ CSS Modules编译时→ CSS-in-JS运行时→ 回归编译时四个阶段2026 年最佳平衡点是 CSS Modules CSS 自定义属性 layerCSS-in-JS 的运行时成本SSR 性能、包体积是回归编译时方案的主因BEM 在简单项目中仍然可用但缺乏编译器级别的安全保障零运行时 CSS-in-JSPanda CSS, Vanilla Extract是兼顾 colocation 和性能的折中方案选择方案时优先看维护方式和渲染路径不要只看语法偏好
双梁正问题 【 torch 实战】（Python代码实现）)
