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 污染：结构和样式纠缠成灾
来看一个真实例子：
scss
<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 能帮我合成组件级样式，比如：
less
.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，我建议你做这几件事
- 强制使用
@apply形成组件级 class，不允许直接使用长串 class； - 抽离公共样式，写在一个统一的组件样式文件中；
- 和设计团队对齐 Tailwind 的 spacing/font/color；
- 用 tailwind.config.js 做好 token 映射和语义名设计；
- 每个页面都进行 CSS code review，不然很快就会变垃圾堆。