logo

Tailwind CSS 好在哪

Authors
  • avatar
    Name
    White Play
    Twitter

视频版

1. 命名之痛

我第一个想到的优势是不用命名了。

有一种说法，软件开发两大难题：一个是缓存，另一个是命名。

尤其是给样式类命名，诶呀，真的太难了。大多数情况下，我们给 class 命名的方法就是，如果是容器就叫 xx-wrapper，wrapper 里面就叫 item，再具体就是 item-title/item-button。

可有的时候布局变了，就需要额外套一层 div，这时候难题来了。按照惯例应该叫 xx-wrapper 对吧，可这就重名了，那咋办？这时候就能看出起名变得不容易了，对吧。

你可能会想到新的单词，比如叫 xx-container，看似解决问题了实则让 className 原有的规则变得更混乱了，因为你不知道什么时候用 container，什么时候用 wrapper。二者区别是啥？

而且如果下次再加了一层 div，那该咋办？

后来为了解决这个命名问题有了 BEM 规范 或者它的一些变体。

简单来说就是直接用横线连接 DOM 结构的方式来给 class 命名——不怕嵌套的层级太多导致我们词穷，只需要往上加横线就行了。

举一个例子：upload 里面的列表就叫 upload-list，再里面每个项就叫 upload-list-item，再里面就叫 upload-list-item-name，就这样一直加横线垒上去就好。

这种 className 命名方式挺好的，让我们在有限的单词量和层层嵌套的 DOM 结构之间寻找到了一种平衡。

所以后来 Tailwind 的出现仿佛在说，哥们别费劲了，敲那么多横线有啥用啊，有这功夫不如干点有用的，你不如直接把长宽高写这，至少一眼能看出来作用是啥。

2. 自动化清理屎山

无论大厂小厂，不管你们团队平常有没有 code-review，代码规范多严格，测试覆盖率有多高，你都得承认 CSS 是代码质量最薄弱的一环。大多数 CSS 代码没人在乎，只要组件样式看起来没问题就好。为啥没人在乎？不是这帮前端不在乎 KPI，而是 CSS 没法测，也很难评判代码质量。

CSS 中文名叫层叠样式表，你理解"层叠"的含义，就知道这玩意为啥没法测、不好维护。层叠意味着你没法单独看一个样式类的定义、写法就能评判它的好坏。它受它若干个父级、子级方方面面的影响。当若干个样式类堆在一起，复杂度极大的提高，最终，你不放到浏览器里就不知道究竟会渲染成什么样。

所以，就算你是经验很丰富的前端，也不敢轻易去修改前人留下的 CSS 文件。想修改前人代码？别改了，往上覆盖吧，这不是你的错，这叫层叠！这就是这门语言的特性。这就导致 CSS 文件都是屎山和重复代码，根本没法看。只有出错了才有人捏着鼻子去粪坑里看看到底怎么回事，而且也不改，再垒一层屎就完事了。

况且我已经记不清我给多少个 xx-wrapper 里写过 display: flex 了。

好在写 Tailwind 时，这种拉屎的负罪感大大减少了。

一方面是因为 CSS 文件几乎被消灭殆尽了。 另一方面，在构建时 Tailwind 会自动化合并同类屎，哪怕写一万遍 display: flex 构建后也就只剩一句话 .flex { display: flex }，这在大型项目里很有用，可以有效减少 CSS 文件尺寸。

3. 其他优势

  • 后端学 CSS 法宝：无需深入 CSS 高级内容，比如各种选择器（+、*、~、,、空格、> 还有伪类伪元素）都不用学，直接用预设就行，用预设就不会太丑。甚至不用学各种单位就可以实现各种尺寸屏幕的适配。大的就 lg，想要小的就 sm，再大就 xl，买过衣服就能明白。

  • 方便实现深色模式：没有 Tailwind CSS 想给页面实现个深色模式可就不容易了，可能需要设定一堆颜色变量，再配合媒体查询，实现起来比较复杂的地方是你不得不给每一个用到的颜色都设定一个变量，因为它们在深色模式下就可能完全是另一套色值；但 Tailwind CSS 只需要加个 dark 前缀。

  • 共置：不需要新建个 CSS 文件，然后来回跳转查看具体内容。有的时候我写个 div 只是因为想让里面的内容居中，Tailwind 顺手就能实现，但传统 CSS 我还得想个名，再跳转到 CSS 文件里去，再重复写一堆代码。总之 Tailwind CSS 很省事。

  • AI 喜欢：可能也是因为共置的原因，不需要横跨几个文件，对 AI 来说无论读还是写都很容易。另外 Tailwind CSS 原子样式类避免选择器、样式继承、样式覆盖，这对 AI 来说也能减少理解难度。

  • 扒别的 Tailwind 写的网站样式直接复制就可以了：比如我这有个网站 https://io.google/2025/，假如我喜欢某个地方的设计，我直接复制粘贴就能化为己用。开源共享从未如此轻松。

  • 便于多人协作：或者说不用花费精力去理解别人的 class 命名和 CSS 结构，也许你也经历过，跟你一起开发的同事可能是写 CSS 特别讲究的人，有一整套 reset，然后类似图层似的引入好几个 CSS 文件相互叠加，导致样式的权重很混乱，你写的样式常常不生效。你又没法说他，因为你队友觉得他这套东西格外讲究，是优秀的工程实践。但如果用 Tailwind CSS 就没那么多破事了，往上糊就完事了。

  • UI 组件：一些牛逼的组件库是基于 Tailwind 开发的，如 shadcn/ui 和 magicui。如果不拥抱 Tailwind 你就可能和它们无缘。尤其是 shadcn-ui，它完全不同于 Element UI 或者 Ant Design 这些组件库，如果你写一些后台管理系统类的项目，可能对前端要求不高，直接拿这 Element 或 Ant Design 堆砌就能快速完活，但如果是 C 端项目，或者对前端要求比较高的项目，往往需要对组件做很多二次开发，像 Element UI 就很难二次开发，你只能基于有限的 props 或样式覆盖来实现定制化，但这个 shadcn-ui 就直接把组件源码生成在项目源码里，这种特性可以说就是为二开而生，具体后期在别的视频细说。点点关注啊。

  • 最后说一个我觉得很重要的一点：它可以帮你去约束 UI 设计师。尤其是如果你们公司 C 端项目比较多，UI 设计师比较有想法的话，那 C 端组件库其实根本没法搞，光一个按钮设计师能搞出一堆设计出来，组件库咋封装吗，但如果选型用 Tailwind CSS，那各种颜色主要哪些色号，页面设计图主要布局的宽高，间距你得让设计师给你提前约定好。这样 UI 设计师在设计的时候至少收着点，不至于太奔放。组件也就有了复用的可能。