为什么我不再相信 Tailwind？三个月重构项目教会我的事

Tailwind 曾经是我最爱的工具，直到它让我维护不下去整个项目。

前情提要：我是如何变成 Tailwind 重度用户的

作为一个多年写 CSS 的前端，我曾经深陷“命名地狱”：

什么 .container-title, .btn-primary, .form-item-error，一个项目下来能写几百个类名，然后改样式时不知道该去哪动刀，甚至删个类都心慌。

直到我遇见了 Tailwind CSS——一切原子化，想改样式就加 class，别管名字叫什么，直接调属性即可。

于是我彻底拥抱它，团队项目里我把所有 SCSS 全部清除，组件中也只保留了 Tailwind class，一切都干净、轻便、高效。

但故事从这里开始转变。

三个月后的重构期，我被 Tailwind“反噬”

我们的后台管理系统迎来一次大版本升级，我负责重构 UI 样式逻辑，目标是：

• 
  
• 统一设计规范；
  
• 提高代码可维护性；
  
• 降低多人协作时的样式冲突。
  

刚开始我信心满满，毕竟 Tailwind 提供了：

• 
  
• 原子化 class；
  
• @apply 合成组件级 class；
  
• 配置主题色/字体/间距系统；
  
• 插件支持动画/form 控件/typography；
  

但随着项目深入，我开始发现 几个巨大的问题，并最终决定停用 Tailwind。

一、class 污染：结构和样式纠缠成灾

来看一个真实例子：

<div class="flex items-center justify-between bg-white p-4 rounded-lg shadow-sm border border-gray-200">

  <h2 class="text-lg font-semibold text-gray-800">订单信息</h2>

  <button class="text-sm px-2 py-1 bg-blue-500 text-white rounded hover:bg-blue-600">编辑</button>

</div>

你能看出这个组件的“设计意图”吗？

你能快速改它的样式吗？

一个看似简单的按钮，一眼看不到设计语言，只看到一坨 class，你根本不知道：

• 
  
• px-2 py-1 是从哪里决定的？
  
• bg-blue-500 是哪个品牌色？
  
• hover:bg-blue-600 是统一交互吗？
  

Tailwind 让样式变得快，但也让样式“变得不可读”。

二、复用失败：想复用样式还得靠 SCSS

我天真地以为 @apply 能帮我合成组件级样式，比如：

.btn-primary {
@apply text-white bg-blue-500 px-4 py-2 rounded;

}

但问题来了：

• 
  
• @apply 不能用在媒体查询内；
  
• @apply 不支持复杂嵌套、hover/focus 的组合；
  
• 响应式、伪类写在 HTML 里更乱，如：lg:hover:bg-blue-700；
  
• 没法动态拼接 class，逻辑和样式混在组件逻辑层了。
  

最终结果就是：复用失败、样式重复、维护困难。

三、设计规范无法沉淀

我们设计系统中定义了若干基础变量：

• 
  
• 主色：#0052D9
  
• 次色：#A0AEC0
  
• 字体尺寸规范：12/14/16/18/20/24/32px
  
• 组件间距：8/16/24
  

本来我们希望 Tailwind 的 theme.extend 能承载这套设计系统，结果发现：

• 
  
• tailwind.config.js 修改后，需要全员重启 dev server；
  
• 新增设计 token 非常繁琐，不如直接写 SCSS 变量；
  
• 多人改配置时容易冲突；
  
• 和设计稿同步代价高。
  

这让我明白：配置式设计系统不适合快速演进的产品团队。

四、多人协作混乱：Tailwind 并不直观

当我招了一位新同事，给他一个组件代码时，他的第一句话是：

“兄弟，这些 class 是从设计稿复制的吗？”

他根本看不懂 gap-6, text-gray-700, tracking-wide 分别是什么意思，只看到一堆“魔法 class” 。

更糟糕的是，每个人心中对 text-sm、text-base 的视觉认知不同，导致多个组件在微调时出现样式不一致、间距不统一的问题。

Tailwind 的语义脱离了设计意图，协作就失去了基础。

最终决定：我切回了 SCSS + BEM + 设计 token

我们开始回归传统模式：

• 
  
• 所有组件都有独立 .scss 文件；
  
• 使用 BEM 命名规范：.button, .button--primary, .button--disabled；
  
• 所有颜色/间距/字体等统一放在 _variables.scss 中；
  
• 每个组件样式文件都注释设计规范来源。
  

这种模式虽然看起来“原始”，但它：

• 
  
• 清晰分离结构和样式；
  
• 强制大家遵守设计规范；
  
• 组件样式可复用，可继承，可重写；
  
• 新人一眼看懂，不需要会 Tailwind 语法。
  

总结：Tailwind 不是错，是错用的代价太高

Tailwind 在以下场景表现极好：

• 
  
• 个人项目 / 小程序：快速开发、无需复用；
  
• 组件库原型：试验颜色、排版效果；
  
• 纯前端工程师独立开发的项目：没有协作负担。
  

但在以下情况，Tailwind 会成为维护灾难：

• 
  
• 多人协作；
  
• UI 不断迭代，设计语言需频繁调整；
  
• 有强复用需求（组件抽象）；
  
• 与设计系统严格对齐的场景；
  

我为什么写这篇文章？

不是为了黑 Tailwind，而是为了让你在选择技术栈时更慎重。

就像当年我们争论 Sass vs Less，今天的 Tailwind vs 原子/语义 CSS 并没有标准答案。

Tailwind 很强，但不是所有团队都适合。

也许你正在享受它的爽感，但三个月后你可能会像我一样，把所有 .w-full h-screen text-gray-800 替换成 .layout-container。

尾声：如果你非要继续用 Tailwind，我建议你做这几件事