Tailwind CSS 与 CSS Modules 各有适用场景：前者通过 utility-first 提升开发效率与维护性，但需规避动态 class 拼接、精准配置 content 路径、放弃隐式继承；后者依赖局部作用域，适合深度嵌套项目，但易导致命名冲突与复用困难。
Tailwind CSS 和 CSS Modules 不是“谁更好”的问题，而是“在哪种场景下更少出错、更省维护成本”。如果你的项目已经用 CSS Modules 跑了两年以上，组件分散、样式嵌套深、composes 和 @import 混用，那直接切 Tailwind 并不会自动变好——它只是把“命名冲突”和“样式复用难”这两个痛点，换成了“class 冗长”和“PurgeCSS 误删”两个新问题。
为什么 Tailwind 的 className 会变多、变长？
这不是设计缺陷，是 utility-first 的必然结果。CSS Modules 里一个 .card-header 类可能封装了 padding、font-weight、border-bottom 三组规则；Tailwind 则拆成 px-4、font-semibold、border-b 三个独立 class。好处是组合自由、无隐式继承；坏处是 JSX 中 class 字符串容易超长，尤其在响应式 + 伪类叠加时（比如 md:hover:bg-blue-600 focus:ring-2）。
常见错误现象：
- 手动拼接字符串导致 PurgeCSS 扫不到：例如
className={`text-${color}-500`}—— 生产环境该样式直接消失 - 滥用
@apply封装复杂组合，反而失去原子性优势，还绕过 JIT 编译优化 - 没配好
tailwind.config.js的content字段，导致部分页面 class 被摇掉（比如漏了src/app/**/*.{js,ts,jsx,tsx}）
CSS Modules 的局部作用域，在 Tailwind 里怎么替代？
Tailwind 本身不提供作用域隔离，它靠的是“约定 + 工具链”来规避冲突：所有 utility class 都是全局的，但只要你不用动态拼接、不写自定义 class 名（比如避免 my-custom-button），就不会有命名污染。真正的隔离来自组件边界和文件组织。
立即学习“前端免费学习笔记（深入）”；
使用场景中要注意：
- 不要在 Tailwind class 上叠加自定义 class 做逻辑分组（如
class="btn-primary bg-blue-500"），这会让btn-primary变成无意义的壳 - 需要复用样式组合时，优先用
@layer components封装，而不是提取成 JS 变量或 React 组件属性 - 如果项目仍需局部作用域（比如微前端子应用间样式隔离），得配合 CSS-in-JS 或 Shadow DOM，Tailwind 单独做不到
开发时看不到实时样式预览？VS Code 插件配错是主因
bradlc.vscode-tailwindcss 插件依赖 tailwind.config.js 的 content 配置做语法提示和悬停查看。配错路径，插件就“失明”——你敲 bg- 不弹提示，悬停也看不到对应 CSS 规则。
实操建议：
- 确保
content明确列出所有含 class 字符串的文件后缀，包括.mdx、.astro、.vue（如果项目里有） - 不要写
"./src/**/*"—— 这会扫描node_modules，构建变慢，且可能误匹配无关字符串（比如日志里的bg-red-500） - 检查插件是否读到配置：VS Code 状态栏右下角应显示 “Tailwind CSS” 并带版本号，否则说明插件未加载成功
最常被忽略的一点：Tailwind 不是“写了就能用”，它要求你放弃对选择器层级的依赖。CSS Modules 里可以靠 .card .header 控制嵌套样式，Tailwind 里必须显式加 class 到目标元素上——这意味着你要习惯把样式决策从“写选择器”变成“改 JSX 属性”，这个思维切换比学习 class 名称难得多。
