作者：ErpanOmer
https://juejin.cn/post/7512652304745037865
“Tailwind 写得越多，越觉得混乱”“组件样式重复一堆”“设计师完全看不懂这坨 className”…
这些反馈你是否也听说过？
Tailwind CSS 被誉为“实用优先的 CSS 框架”，然而在实际项目中，很多团队用了 Tailwind，效率却不升反降。
不是因为 Tailwind 本身不行，而是——你可能正踩在这些使用误区上。
本文将围绕 6 个常见误区，逐一剖析：
-
把 Tailwind 当成原子 CSS 的“组合器” -
滥用 @apply和组件式提取 -
不配置 Design Token，直接用默认色板 -
缺少抽象语义类的规范 -
无视团队协作中的语义歧义 -
不懂插件生态和可配置性，白白造轮子
误区一：把 Tailwind 当成“低配版 SCSS”来写
有些团队习惯了 BEM 或 SCSS 的写法，迁移 Tailwind 后陷入一个坑：
“我只会把 .title {} 改写成 <div class="title">，然后 .title 用 @apply text-lg font-bold 合成”
结果就是：
-
每个组件依然维护 .xxx { @apply ... } -
每个 class 被重复“硬编码”，没有复用价值 -
真正的 Tailwind 优势（原子化组合）彻底失效
这其实是把 Tailwind 当成 SCSS 的语法糖在用，不仅没提高效率，反而多了一层“拼贴工”。
建议：
-
组件中直接使用原子类组合，不要回退为传统 class 命名法 -
通过抽象语义 class（例如 btn-primary）统一复杂样式，避免 @apply 滥用
误区二：滥用 @apply，导致样式复用变得更难维护
Tailwind 支持 @apply，但很多人误解它是“推荐方式”。结果就是：
.btn {
@apply px-4 py-2 rounded-md bg-blue-500 text-white;
}
.btn-secondary {
@apply btn bg-gray-500;
}
这本质上已经偏离了 Tailwind 的精神。问题在于：
-
@apply 语义缺失，又回到了传统 CSS 的“找 class 写样式”流程 -
一旦 .btn修改，影响范围不可控（链式引用） -
无法动态响应状态（例如 hover:bg-blue-600、dark:bg-blue-400）
正确方式：
-
抽象出来的 class 应该直接写在 class=""中，比如class="btn btn-primary" -
配合 UnoCSS 或 Tailwind plugin，使用 语义化原子类 实现动态组合（见下文）
误区三：直接使用 Tailwind 默认色板，导致主题难以统一
许多初学者习惯直接写：
<div class="bg-blue-500 text-gray-800">按钮</div>
看起来没毛病，但：
-
“blue-500” 具体代表什么品牌色？设计稿里用的是 #378AFF 你知道吗？ -
一旦品牌换主色，100 个组件都要人工搜索替换？ -
多人项目中，“每个人对 text-sm 的认知都不同”
这不是视觉认知问题，而是你没有建立设计 token 体系。
推荐配置方式（tailwind.config.ts）：
theme: {
colors: {
brand: {
DEFAULT: '#378AFF',
dark: '#2563EB',
light: '#93C5FD'
}
},
fontSize: {
base: '16px',
sm: '14px',
lg: '18px'
}
}
然后组件中统一用 bg-brand text-sm，做到真正的“设计系统驱动”。
误区四：class 混乱、语义缺失，导致组件难复用
很多初级 Tailwind 项目里的组件看起来像这样：
<div class="px-4 py-2 rounded-md bg-blue-500 text-white text-sm shadow-md hover:bg-blue-600">
提交
</div>
逻辑没问题，但：
-
这个组件到底是按钮？标签？还是 Toast？ -
想要复用时只能 copy-paste，一改就坏 -
业务迭代时，10 个类似组件居然样式不同（改过一点 padding、换了一个 shadow）
Tailwind 推荐语义化命名 + utility 组合方式，例如：
<button class="btn btn-primary">提交</button>
然后在 tailwind.config.ts 里添加：
plugins: [
require('@tailwindcss/forms'),
function ({ addComponents }) {
addComponents({
'.btn': {
@apply px-4 py-2 rounded-md text-white text-sm;
},
'.btn-primary': {
@apply bg-brand hover:bg-brand-dark;
}
})
}
]
不仅可复用，还能集中管理样式变更。
误区五：团队协作不统一，样式风格“各写各的”
当团队使用 Tailwind 却没有协作规范时，经常出现以下现象：
-
A 开发写 text-sm, B 写text-xs，页面出现 4 种字号 -
有的写 rounded, 有的写rounded-md，风格混乱 -
多人维护组件时，一改颜色就影响全局，因为写死在组件里
Tailwind 鼓励显式地“写出来”，但这不代表可以无限自由拼接。
解决方式：
-
建立 token 规范：颜色、字体、尺寸统一配置 -
使用 @shadcn/ui作为组件层抽象（推荐组合 Tailwind + Radix + shadcn） -
使用 ESLint 插件强制校验 Tailwind class 的顺序和规范（如 eslint-plugin-tailwindcss）
误区六：没用插件、没开 JIT、错失生态红利
很多团队用了 Tailwind，但配置还停留在最基本阶段：
-
没开 JIT 模式（Just In Time 构建） -
没启用 dark mode（Tailwind 支持类选择器控制 dark 样式） -
没接入 tailwind-variants / clsx / cva 等原子类组合库 -
对 UnoCSS 完全不了解（其实比 Tailwind 更自由，兼容性好）
Tailwind 的能力远不止于“写几个 class”——它已经是一个完整的样式编程语言了。
举个例子：
你可以使用 tailwind-variants 这样写组件样式组合：
const button = tv({
base: 'inline-flex items-center justify-center font-medium',
variants: {
intent: {
primary: 'bg-brand text-white hover:bg-brand-dark',
secondary: 'bg-gray-100 text-gray-800 hover:bg-gray-200'
},
size: {
sm: 'text-sm py-1 px-2',
md: 'text-base py-2 px-4'
}
}
})
然后在组件中使用：
<button className={button({ intent: 'primary', size: 'md' })}>按钮</button>
写起来干净，组合灵活，完全符合设计系统的思想。
✅ 正确的 Tailwind 使用思维：构建语义原子设计系统
Tailwind 的真正优势不在于“快”，而在于：
构建一套“视觉样式与设计语言一致”的原子组件体系。
好的实践是：
-
所有颜色、字号、间距抽象为 Design Token -
所有组件样式统一在配置文件或 plugin 中抽象复用 -
使用 shadcn/ui+tailwind-variants+clsx构建语义组件库 -
使用 prettier-plugin-tailwindcss+ ESLint 强化规范 -
页面代码中只使用 最小必要 class + 语义化 class -
样式变化驱动来自配置层变动，而非组件层硬改
最后
Tailwind 并不是魔法，它只是一个极致实用主义的 CSS 工具包。
真正的工程实践中，Tailwind 的效率取决于你是否理解并规避以下误区：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---END---
推荐阅读：
【收藏必备】8 张脑图快速了解 Vue 组件
新搭建一个 Vue 项目后，我有了这 15 点思考 从 0 到 1 搭建一个企业级前端开发规范
最近面试BAT，整理一份面试资料《前端面试BAT通关手册》，覆盖了前端技术、CSS、JavaScript、框架、 数据库、数据结构等等。 获取方式：关注公众号并回复 前端 领取，更多内容陆续奉上。 明天见(｡･ω･｡)ﾉ♡