作者认为Tailwind CSS虽能快速构建界面，但不推荐用于中大型项目。主要原因是需要学习大量工具类，初期开发效率低，且自定义类与框架类混合使用会增加复杂度。

好的，作为一名专业的中文编辑，我将对这篇英文文章进行中文重述，保留核心观点和细节，同时删减与主题无关的冗余内容。

为什么我不推荐Tailwind CSS

Tailwind CSS 是一个广受欢迎的 CSS 框架，它通过预设的间距、颜色和尺寸标准，帮助开发者快速构建界面，尤其适合没有设计背景的人。然而，尽管我曾用它快速完成过多个项目，但我认为它并非适用于所有场景。在决定是否在中等或大型项目中使用它之前，你需要三思。

1. 需要记忆大量类名

Tailwind 拥有数千个工具类。即使文档优秀且编辑器有自动补全，你仍需掌握大量基础类名。初期开发时，你可能需要频繁查阅文档，理解每个类的最佳用法，这个过程相当缓慢。如果你还混用了自定义类，难度会进一步增加。

2. 打破了结构与设计的分离

Tailwind 是一个庞大的原子类库，除非你使用 @apply 指令，否则你会在 HTML 中嵌入大量类名。这破坏了“结构与设计分离”（即 HTML 与 CSS 分离）的经典原则，导致 HTML 臃肿、可读性下降，并失去了可复用性。

Tailwind 的创造者 Adam Wathan 对此的辩护是：分离的关注点并未消失，只是方向改变了。在“语义化”CSS 中，CSS 依赖 HTML；而在工具类中，HTML 依赖 CSS。耦合依然存在，只是方向不同。这个论点在组件化架构（如 React 或 Vue）中成立，因为逻辑、标记和样式本就在同一文件中。但在服务端渲染的项目中，传统的分离方式仍然完全合理。

3. 命名不一致

Tailwind 的命名有时不直观且令人困惑。例如，items-center、justify-center、text-center 和 place-content-center 都涉及“居中”，但作用对象和场景完全不同。如果命名更一致，比如 flex-align-items-center，会清晰得多。其他例子如 justify-center 和 items-center（而非 align-center）也体现了这种不一致。这些小摩擦会累积起来。

4. 设计系统并非强制

Tailwind 的间距和颜色体系确实有助于保持一致性，但“任意值”功能（如 w-[347px]）是一个破坏系统的“逃生舱口”。它允许你绕过预设，使用任意值。同样，你可以在同一个项目中混用 sky-400 和 blue-400。一致性最终仍取决于你的自律，而非框架本身。

5. 不利于学习 CSS

对于 CSS 经验不足的开发者，Tailwind 会营造一种“学会了”的假象。使用大量预制类会阻碍你真正掌握 CSS 基础。例如，pt-4 需要你在脑中翻译成 padding-top: 1rem。你熟练的是抽象层，而非 CSS 本身。我建议先学习 CSS，再接触 Tailwind。对于经验丰富的开发者，甚至可能根本不需要这个框架。

6. 可读性差

对比一个按钮的样式：原生 CSS 代码自解释，易于维护，新开发者上手成本低。而 Tailwind 的 @apply 版本（如 @apply py-2 px-4 bg-indigo-500...）则需要查阅文档才能理解 bg-indigo-500 是什么颜色、rounded-lg 有多圆。有趣的是，Adam Wathan 本人也承认 @apply 的存在“基本上只是为了欺骗人们”，如果重写 Tailwind，他不会加入这个功能。这意味着，你用来恢复可读性的方法，恰恰违背了 Tailwind 的哲学。

7. HTML 在优先级上误导你

在 CSS 中，选择器的优先级由样式表中的顺序决定，而非 HTML 中类名的顺序。Tailwind 的问题在于，你无法通过调整 HTML 中类名的顺序来解决优先级冲突。例如，<p class="text-red-500 text-green-500"> 最终显示为红色，因为最终样式表中 text-red-500 的定义在后。HTML 中的顺序是无效的，这被称为“泄漏的抽象”。它承诺了简单，却迫使你去了解其底层机制。

8. 开发者工具体验不佳

当组件包含大量类名时，在浏览器检查器中排查样式会变得缓慢。你需要滚动查找哪些样式生效、哪些被覆盖。而原生 CSS 则能让你快速定位问题。

结论：为什么不直接用现代 CSS？

如今的原生 CSS 已经非常强大，提供了级联层、原生嵌套、自定义属性、容器查询等特性。讽刺的是，Tailwind 本身正是构建在这些特性之上的。如果平台本身已经提供了这些能力，Tailwind 的“必要性”还剩多少？

当然，原生 CSS 提供了功能，但没有提供约束系统、样式与标记的“就近存放”以及自动补全。在小型或服务端渲染项目中，现代 CSS 本身就是一个很好的选择。而在大型、多人协作的组件化产品中，Tailwind 仍有其价值。没有绝对的赢家，只有适合的上下文。

总而言之，Tailwind 并非一个坏工具，但它是一个需要你在未来付出代价的工具。如今，它还要与功能更强大的原生 CSS 竞争。在选择它之前，请先学好 CSS，然后做出明智的决定。你今天节省的初期努力，未来可能需要加倍偿还。

根据评论内容，总结主要观点如下：

支持Tailwind的观点： 1. 实用高效：Tailwind能快速构建项目，降低开发时间（评论13："it reduces the time to build"）。开发者可快速上手，长期维护也方便（评论8："projects with Tailwind work. Over years"）。 2. 解决CSS痛点：传统CSS在大型项目中易变成"意大利面条式代码"，Tailwind通过约定和类名解决了这一问题（评论29："large CSS requires a lot of active effort to prevent it becoming spaghetti code"）。 3. 可复用性强：Tailwind元素可轻松复制到其他项目并保持外观一致（评论25："I can copy any cool-looking Tailwind element... it'll look exactly the same"）。 4. 学习曲线合理：虽然需要记忆基础类名，但自然且可查（评论8："The conventions and class names come really naturally fast"）。

反对或质疑Tailwind的观点： 1. 破坏语义化：Tailwind的类名方式违背了HTML/CSS分离的传统理念（评论16："separation of structure and style are a good thing"）。有评论认为这是"AI slop"（评论1："like AI slop"）。 2. 缺乏前端工程领导力：使用Tailwind的组织往往缺乏资深前端工程师（评论17："organizations void of any skilled frontend engineering leadership"）。 3. 过度依赖工具：Tailwind的"逃生舱"（如@apply）可能被滥用（评论14："escape hatches bad"）。有评论认为"just use modern CSS"更差（评论20）。 4. 替代方案存在：CSS Modules等方案能更好地解决类名冲突问题（评论21："CSS Modules are a better solution"）。

中立或折中观点： 1. 工具选择取决于项目：Tailwind适合特定场景，如个人项目或团队协作（评论6："small devoper-led side-projects are where it is a good fit"）。 2. CSS本身是问题根源：Tailwind只是将问题向正确方向移动（评论7："The problem isn't tailwind, it's css"）。 3. 传统方法也有缺陷：BEM等语义化方案在实践中难以坚持（评论24："BEM... only works if all devs strictly follow the convention"）。

关键引用保留： - 支持："projects with Tailwind work. Over years"（评论8） - 反对："organizations void of any skilled frontend engineering leadership"（评论17） - 中立："The problem isn't tailwind, it's css"（评论7）