Julia Evans 用了大约 8 年 Tailwind，最近把几个个人网站迁到了更语义化的 HTML 和原生 CSS。

有意思的不是“Tailwind 输给了原生 CSS”。这句话太大，也不符合原文。真正值得看的是：一个不是全职前端的技术作者，在多年项目里慢慢补齐 CSS 能力后，开始不再满足于让工具替自己划边界。

她给出的原因很具体。新版 Tailwind 对构建系统依赖更强；旧项目里直接引入 2.8MB 的 tailwind.min.css 显得笨重；原生 CSS 和 Tailwind 混在一起，也让维护变得别扭。

这不是行业趋势报告。更像一个小型网站维护者的清醒账本：工具曾经帮过忙，但项目走到某个阶段，工具本身也会变成一层负担。

从 Tailwind 迁出，不等于否定 Tailwind

Evans 早年喜欢 Tailwind，很大原因是她当时还不知道怎样组织 CSS。

这点很真实。很多人不是不会写 color、margin、display，而是不知道样式文件长大以后怎么不互相污染。Tailwind 当时给她的价值，不只是工具类，还包括 reset、颜色体系、字号阶梯和一套可复用的默认秩序。

她后来迁移时，甚至沿用了 Tailwind preflight reset 的思路，复制了前面约 200 行。这说明她不是推倒重来，而是在把 Tailwind 里有用的部分拆出来，放回自己的项目结构里。

变化出在两个地方。

一是项目里同时存在 Tailwind 和手写 CSS，维护成本上来了。二是她自己的 CSS 能力变强了，已经可以自己设计一套边界，而不是继续把 padding、margin、断点都塞进 HTML class。

问题Tailwind 曾解决什么迁移后的做法这里的判断
浏览器默认样式preflight reset 提供统一起点沿用类似 reset不是否定 Tailwind
颜色和字号提供可复用的阶梯用 CSS 变量重建保留系统感
组件样式用工具类快速组合按组件拆 CSS 文件更强调边界
响应式布局用断点类处理变化更多依赖 CSS Grid更吃 CSS 基本功
工程依赖框架处理生成和裁剪开发期用原生 import，生产可用 esbuild 打包小项目可减负

所以这篇文章最容易被误读的地方，恰恰是标题感最强的地方。它不是“Tailwind 不行了”，而是“当你知道自己要什么，框架的默认答案就未必最顺手”。

她重建 CSS 的核心，是给组件划边界

Evans 新结构的重点不是“少写 class”。重点是按组件组织 CSS。

她的做法大致是：每个组件有一个明确 class；每个组件对应独立 CSS 文件；一个组件的样式尽量不要覆盖另一个组件。她没有用 Web Components，也没有依赖 CSS @scope 来强制隔离，而是先靠命名和文件结构建立纪律。

这听起来朴素，但对小型网站很够用。

很多个人站、文档站、技术作者的产品页，问题不在于缺少一套大型前端架构，而在于样式散在各处。今天为了一个卡片写几行 CSS，明天为了一个页面覆盖几条规则，半年后谁也不敢删。

现代 CSS 也让这种回归更可行。变量、嵌套、import、Grid 都已经成熟不少。Evans 特别提到 auto-fit、minmax、grid-template-areas 这类能力，可以减少媒体查询，也让布局表达更接近“我想要什么”，而不是“我该拼哪些工具类”。

这里有一个现实限制：原生 CSS 不是自动更简单。

如果没有命名规则，没有组件边界，没有变量体系，手写 CSS 很快会回到老问题：级联失控、覆盖失控、删除困难。尾大不掉，不是框架独有的问题。

对前端开发者来说，这篇文章可以转成一个很直接的动作：

你的现状更适合的动作
主要写产品组件，多人协作，已有设计系统不必因为这篇文章迁出 Tailwind，先守住团队一致性
小型网站混用 Tailwind 和手写 CSS，覆盖越来越多可以先迁 1-2 个组件，验证组件化 CSS 是否更清楚
经常为了 Grid、复杂布局绕开工具类把布局层抽到原生 CSS，保留 Tailwind 处理简单间距和文本也可以
不清楚 CSS 变量、级联、Grid先别急着迁移，迁出去只是把问题换个地方暴露

对维护个人项目的技术作者，影响更具体：别把“迁移”当成仪式。更稳妥的做法是先挑一个样式边界最乱的页面，把 reset、变量、组件 CSS、布局 CSS 拆清楚。能删掉一批重复 class，再继续；拆完更乱，就停。

接下来该看 CSS 能不能被组织起来

这件事的主线不是框架输赢，而是约束从哪里来。

Tailwind 的约束来自 class 命名和预设系统。它适合让多人写出相对一致的界面，也适合让不想设计 CSS 架构的人快速推进。对企业团队，这种约束仍然有价值。尤其是有设计令牌、代码审查和组件库的团队，贸然迁出未必省事。

原生 CSS 的约束来自开发者自己。变量怎么命名，组件怎么隔离，布局规则放在哪里，哪些样式可以复用，哪些不能跨组件覆盖，都要自己决定。

这也是专业性回来的地方。

过去很多人讨厌 CSS，是因为它看起来没有硬边界。现在 CSS 有了 @layer、@scope、container queries、subgrid 等能力，边界工具更多了。但工具多不等于自动可维护。真正要看的，是开发者和团队能不能把这些能力变成规则。

目前看不清的部分也要说清楚。原文没有提供迁移耗时、性能提升、加载速度改善的量化结果，也没有把这套方法推广到大型团队。能得出的结论只能是：对一部分小型网站和个人项目，原生 CSS 的可维护性重新变得有吸引力。

回到开头那个 2.8MB 的 tailwind.min.css。它不是 Tailwind 衰退的证据，而是一个提醒：当项目很小、结构很清楚、作者也有能力维护 CSS 时，继续背着整套框架，可能已经不是最省心的选择。