CSS 模块化方案有哪些？CSS Modules、CSS-in-JS、Tailwind 怎么选？

详细解析#

全局样式的问题#

所有 CSS 文件最终合在一个全局作用域里。两个组件都写了 .title，后加载的会覆盖先加载的；删掉一段样式时也不敢确定还有没有别处在用。层级越写越深、优先级越堆越高，最后只能靠 !important。

BEM：命名约定#

.block__element--modifier，比如 .card__title--active。类名带上组件前缀，选择器保持一层，优先级扁平、可读性好。缺点是全靠人遵守，名字长，没有工具层面的保证。

CSS Modules 和 Vue scoped#

CSS Modules：构建工具把 Button.module.css 里的类名编译成带哈希的唯一名字（如 Button_primary_a1b2c，具体格式由构建工具配置决定），并导出一个"原名 → 新名"的映射对象，组件里用 styles.primary 引用。需要全局类名时用 :global(.xxx)。

Vue scoped：编译时给组件模板里的元素加上 data-v-xxxx 属性，同时把样式选择器改写成 .title[data-v-xxxx]，这样样式只匹配本组件的元素。子组件的根元素会同时带上父组件的标识，所以父组件可以给子组件根元素加样式；想影响子组件内部，要用 :deep()。

两者都是编译时方案，没有运行时开销，产物还是普通 CSS 文件。

CSS-in-JS#

以 styled-components、Emotion 为代表的运行时方案，在组件渲染时根据 props 生成样式、插入 style 标签。好处是样式和组件同处一处，动态样式写起来自然。代价是：

• 渲染时要序列化样式、计算哈希、插入规则，组件多、更新频繁时有开销
• SSR 需要额外收集渲染过程中产生的样式并注入 HTML，配置复杂
• 依赖 React Context 和客户端运行时，不能直接写在 React Server Components 里，只能用在客户端组件中，并且要库本身适配流式渲染（例如 Next.js App Router 要额外配一个样式收集的 registry）

因此出现了零运行时方案，例如 vanilla-extract、Linaria：写法类似 CSS-in-JS，构建时就抽取成静态 CSS 文件。

Tailwind：原子化 CSS#

每个类名只做一件事，如 flex、p-4、text-gray-500，直接写在 HTML 上组合。构建时扫描源码，只生成用到的类。

• 优点：不用起名，不会冲突；CSS 体积随项目增长很慢；间距、颜色受设计规范约束，风格统一；删组件不会留下无用样式
• 缺点：模板里类名很长，可读性下降；需要记一套类名；复杂样式（如复杂动画、伪元素）写起来别扭

怎么选#

代码示例#

// CSS Modules：Button.module.css 里写 .btn 和 .primary
import styles from './Button.module.css'

export function Button({ primary, children }) {
  // 编译后 class 类似 "Button_btn_x1y2z Button_primary_a1b2c"
  return (
    <button className={`${styles.btn} ${primary ? styles.primary : ''}`}>
      {children}
    </button>
  )
}

<template>
  <div class="card">
    <ChildList />
  </div>
</template>

<style scoped>
/* 编译后：.card[data-v-7ba5bd90] */
.card { padding: 16px; }

/* 修改子组件内部的元素：编译后 .card[data-v-7ba5bd90] .item */
.card :deep(.item) { color: #666; }
</style>

面试官可能追问#

易错点#

• Vue scoped 不是 Shadow DOM，只是编译时加属性选择器，隔离并不彻底
• CSS-in-JS 不等于运行时开销，零运行时方案在构建时就产出静态 CSS
• Tailwind 的类名必须在源码里完整出现，动态拼接会导致样式丢失