告别 Tailwind CSS:如何用原生 CSS 构建可维护的样式架构
程序员 Julia Evans 最近在 Hacker News 上分享了她将项目从 Tailwind CSS 迁移到原生 CSS 的经历,帖子拿到了 379 分和 244 条评论,引发了前端社区的热烈讨论。她用了 8 年 Tailwind,最终选择离开——不是因为 Tailwind 不好,而是因为她从 Tailwind 身上学到了足够多的东西,可以用原生 CSS 自己构建一套更好的体系。
这篇文章将深度拆解她的方法论,并补充大量实战代码示例。如果你正在考虑告别 Tailwind CSS,或者单纯想了解更好的 CSS 架构思路,这篇指南就是为你写的。
目录
为什么要离开 Tailwind CSS
Tailwind CSS 毫无疑问是过去几年最流行的 CSS 框架之一。它的原子化设计理念让开发者可以用类名快速拼装界面,不用写一行自定义 CSS。但随着项目变大,一些问题开始浮现:
- HTML 可读性下降:一个按钮上挂着 20 个类名,想读懂它的样式需要逐个拆解
- 样式复用困难:同样的样式组合在多个地方重复出现,但没有真正的「组件」概念
- 文件臃肿:虽然 Tailwind 有 purge 机制,但生成的 CSS 文件依然偏大
- 调试不直观:浏览器 DevTools 里看到的是一堆工具类,而不是语义化的样式
Julia 的核心观点是:Tailwind 很适合入门和快速原型,但当你真正理解了 CSS 的设计原则后,用原生 CSS 反而能写出更清晰、更好维护的代码。
Tailwind 教会了我们什么
在彻底离开之前,Julia 强调了一个重要观点:Tailwind 是很好的 CSS 教学工具。它教会了很多开发者以下关键概念:
- CSS Reset:现代项目需要一个可靠的 reset 来消除浏览器默认样式的差异
- 色彩系统:不要随便用十六进制颜色,建立一套有层次的调色板
- 字体比例:不要用 13px、14px、15px 这种随意的字号,用一套递增的比例系统
- 间距规范:用一致的间距值(4px、8px、16px、32px)而不是随便填数字
这些从 Tailwind 学来的设计原则,可以直接迁移到原生 CSS 中。关键是把这些知识用 CSS 变量固化下来。
用 CSS 变量构建设计系统
原生 CSS 最大的优势之一是 CSS 自定义属性(变量)。Julia 的做法是把 Tailwind 的设计系统用 CSS 变量重建:
颜色变量
定义在 :root 上,全局可用:
:root {
/* 主色调 */
--pink: #fea0c2;
--blue: #a0d0fe;
--green: #a0fea0;
--yellow: #fefe80;
--purple: #d0a0fe;
/* 中性色 */
--gray-50: #f9fafb;
--gray-100: #f3f4f6;
--gray-200: #e5e7eb;
--gray-500: #6b7280;
--gray-700: #374151;
--gray-900: #111827;
/* 语义色 */
--text: var(--gray-900);
--text-muted: var(--gray-500);
--bg: #ffffff;
--bg-subtle: var(--gray-50);
--border: var(--gray-200);
}
这种做法的好处是:改一次变量,全局生效。想支持暗黑模式?只需要用 @media (prefers-color-scheme: dark) 重新定义这些变量即可。
字体大小比例
直接从 Tailwind 的字体系统迁移过来:
:root {
--size-xs: 0.75rem; /* 12px */
--size-sm: 0.875rem; /* 14px */
--size-base: 1rem; /* 16px */
--size-lg: 1.125rem; /* 18px */
--size-xl: 1.25rem; /* 20px */
--size-2xl: 1.5rem; /* 24px */
--size-3xl: 1.875rem; /* 30px */
--size-4xl: 2.25rem; /* 36px */
}
--size-xs 而不是 --font-size-xs,这样更简洁。团队只需要记住一个命名前缀。
间距系统
:root {
--space-1: 0.25rem; /* 4px */
--space-2: 0.5rem; /* 8px */
--space-3: 0.75rem; /* 12px */
--space-4: 1rem; /* 16px */
--space-6: 1.5rem; /* 24px */
--space-8: 2rem; /* 32px */
--space-12: 3rem; /* 48px */
--space-16: 4rem; /* 64px */
}
CSS 组件化架构
这是 Julia 方法论中最核心的部分。她借鉴了 Vue/React 组件的思想,但用纯 CSS 实现:每个组件有自己唯一的类名和独立的 CSS 文件。
设计原则
- 每个组件用一个独特的类名(如
.site-header、.blog-card、.search-box) - 每个组件有独立的 CSS 文件
- 组件之间绝不互相覆盖样式
- 组件内部可以使用 CSS 变量,但不修改全局变量
文件结构
css/
reset.css /* CSS Reset */
variables.css /* 全局 CSS 变量 */
base.css /* 基础样式 */
components/
site-header.css /* 头部组件 */
blog-card.css /* 博客卡片 */
search-box.css /* 搜索框 */
footer.css /* 页脚 */
utilities.css /* 工具类 */
组件示例:博客卡片
HTML:
<article class="blog-card">
<img class="blog-card__image" src="cover.jpg" alt="封面图">
<div class="blog-card__body">
<h3 class="blog-card__title">文章标题</h3>
<p class="blog-card__excerpt">文章摘要...</p>
<span class="blog-card__date">2026-05-17</span>
</div>
</article>
CSS(components/blog-card.css):
.blog-card {
border: 1px solid var(--border);
border-radius: 8px;
overflow: hidden;
background: var(--bg);
transition: box-shadow 0.2s;
}
.blog-card:hover {
box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
}
.blog-card__image {
width: 100%;
height: 200px;
object-fit: cover;
}
.blog-card__body {
padding: var(--space-4);
}
.blog-card__title {
font-size: var(--size-xl);
font-weight: 600;
margin: 0 0 var(--space-2);
}
.blog-card__excerpt {
font-size: var(--size-sm);
color: var(--text-muted);
margin: 0 0 var(--space-3);
}
.blog-card__date {
font-size: var(--size-xs);
color: var(--text-muted);
}
注意看:.blog-card__title 和 .blog-card__excerpt 之间没有样式冲突,因为它们都在 .blog-card 的命名空间下。这比 Tailwind 的 class="text-xl font-semibold mb-2" 清晰得多。
精简的基础样式
Julia 保持基础样式非常精简,只设置全局需要的默认值:
/* reset.css - 简化的 CSS Reset */
*, *::before, *::after {
box-sizing: border-box;
margin: 0;
}
body {
font-family: 'Inter', 'Noto Sans SC', system-ui, sans-serif;
font-size: var(--size-base);
line-height: 1.6;
color: var(--text);
background: var(--bg);
}
img {
max-width: 100%;
display: block;
}
a {
color: var(--blue);
text-decoration: none;
}
a:hover {
text-decoration: underline;
}
section {
padding: var(--space-8) 0;
}
没有多余的样式,没有全局的 font-size 覆盖,没有复杂的 reset 规则。够用就好。
用 Owl 选择器管理间距
这是 Julia 方法论中最巧妙的部分。Owl 选择器(* + *)是 Heydon Pickering 提出的经典方案,用一行 CSS 解决了组件内部的垂直间距问题:
section > * + * {
margin-top: 1rem;
}
这行代码的含义是:section 内部的任何元素,如果不是第一个,就加一个 margin-top。这意味着你不需要给每个子元素单独设置间距,HTML 里也不需要额外的 wrapper 或 gap。
对比 Tailwind 的写法
Tailwind 版本:
<section class="flex flex-col gap-4">
<h2>标题</h2>
<p>段落</p>
<div>内容</div>
</section>
Owl 选择器版本:
<section>
<h2>标题</h2>
<p>段落</p>
<div>内容</div>
</section>
HTML 更干净,间距逻辑统一在 CSS 里管理。你甚至可以为不同的 section 定义不同的间距:
.hero-section > * + * {
margin-top: var(--space-6);
}
.blog-list > * + * {
margin-top: var(--space-4);
}
.footer > * + * {
margin-top: var(--space-2);
}
margin-top: 0 来覆盖。
容器查询:真正的响应式设计
Tailwind 的响应式设计依赖媒体查询(media queries),但媒体查询是基于视口宽度的,不是基于组件实际可用空间的。CSS 容器查询(container queries)解决了这个问题:
.blog-card {
container-type: inline-size;
container-name: card;
}
/* 当卡片容器宽度 >= 400px 时,改为水平布局 */
@container card (min-width: 400px) {
.blog-card {
display: grid;
grid-template-columns: 200px 1fr;
}
.blog-card__image {
height: 100%;
}
}
这意味着同一个博客卡片组件,在侧边栏里会自动变成紧凑的水平布局,在主内容区则是宽敞的垂直布局——不需要任何 JavaScript,也不需要父组件传 props。
容器查询 vs 媒体查询
/* 媒体查询:基于视口宽度,不精确 */
@media (min-width: 768px) {
.blog-card { /* 视口 >= 768px 时生效 */ }
}
/* 容器查询:基于组件实际宽度,精确 */
@container card (min-width: 400px) {
.blog-card { /* 卡片宽度 >= 400px 时生效 */ }
}
所有现代浏览器都已经支持容器查询(Chrome 105+、Firefox 110+、Safari 16+),可以放心在生产环境使用。
保留必要的工具类
Julia 并没有完全抛弃工具类的概念。她保留了少量真正有用的全局工具类:
/* 无障碍:视觉隐藏但屏幕阅读器可读 */
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border-width: 0;
}
/* 文字截断 */
.truncate {
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
}
/* 容器 */
.container {
max-width: 1200px;
margin-inline: auto;
padding-inline: var(--space-4);
}
这些是真正跨组件通用的工具,数量少、职责明确。跟 Tailwind 那几百个工具类完全不同。
迁移实战指南
如果你正在考虑从 Tailwind 迁移,以下是一个循序渐进的方案:
第一步:建立变量系统
从你现有的 tailwind.config.js 中提取颜色、字体、间距等设计 token,转换为 CSS 变量。这个过程可以半自动化——写个脚本解析 tailwind config 生成 variables.css。
第二步:从小组件开始
不要一次性替换所有样式。选择一两个小组件(比如按钮、卡片),用原生 CSS 重写,其他部分继续用 Tailwind。
第三步:建立 CSS 文件结构
按照前面描述的组件化架构组织 CSS 文件。每个组件一个文件,便于维护和查找。
第四步:逐步替换
每次修改一个页面或组件时,顺便把它的 Tailwind 类名替换为原生 CSS。这样迁移是渐进式的,不会一次性引入大量 bug。
第五步:移除 Tailwind
当所有组件都迁移完成后,从项目中移除 Tailwind 依赖。检查构建配置,确保 CSS 文件被正确打包。
总结
Julia Evans 的经历告诉我们一个重要的道理:好的工具不一定是永久的伙伴。Tailwind CSS 是一个优秀的 CSS 教学工具和快速原型工具,但当你真正理解了 CSS 的设计哲学后,原生 CSS 能给你更大的自由度和更好的可维护性。
核心收获:
- CSS 变量是构建设计系统的基石,比 Tailwind config 更灵活
- 组件化 CSS(一个组件一个文件一个类名)解决了样式的隔离和复用问题
- Owl 选择器用一行代码统一管理组件间距
- 容器查询比媒体查询更精确地实现响应式设计
- 保留少量工具类处理真正跨组件的通用样式
这不是说 Tailwind CSS 不好——它在快速原型和小型项目中依然是极佳的选择。但对于需要长期维护的中大型项目,掌握原生 CSS 的架构能力是一项值得投资的技能。
推荐阅读:Julia Evans 的原帖 New CSS things I learned,以及 Heydon Pickering 的 Lobotomized Owl 选择器 原文。