三年前，我开始使用tailwind css，一个出色的前端开发库（本文不再赘述其优点，网上资源丰富）。我想分享一下我早期使用tailwind时不断犯的错误，希望能帮助大家避免重蹈覆辙。
Tailwind颠覆了传统CSS的级联样式表概念，通过“实用程序类”将CSS规则直接应用于DOM元素。起初感觉陌生，但很快便上手了。我仅用一天时间就适应了它，现在除非不得已，否则不会再写纯CSS了。Tailwind与我的首选框架Nuxt集成无缝，构建美观、响应式网站非常便捷。
然而，问题出现了：选项越多，包含的样式越多，HTML代码就越混乱。另一个问题是代码冗余。作为一名DRY原则的忠实拥护者，看到模板中重复的类序列让我非常难受。
我尝试优化它。
最初的想法是将Tailwind类序列提取为字符串变量。在Vue.js（Nuxt基于Vue）中，大致如下：
虽然维护和修改更容易了，但代码可读性却值得商榷，尤其是在应用中有多个相同元素，需要将定义提升到全局常量时。
我继续寻找更好的解决方案，这时我发现了Tailwind的@apply指令。这似乎与之前的做法背道而驰：你可以创建自己的“类样式表”，用自定义类和元素填充它，而不是直接将定义放在具体元素上。不同的是，你可以用Tailwind实用程序类构建解决方案，而不是简单的CSS规则。
虽然Vue School的导师和Tailwind文档都警告我不要使用@apply，但我还是尝试了。
我用这种方法创建了几个网站，它确实有效。问题解决了，或者说…暂时解决了？
到了2024年末，我为一个网站添加新功能时，完全忘记了一年前用@apply做的“恶作剧”。突然，我发现无法组合布局。
模板中没有明显的样式，但 经过一番排查，我找到了罪魁祸首： 在 谁会想到我有一天需要其他样式呢？ 教训一：永远不要在元素选择器上全局使用 虽然在创建新项目时它看起来很方便，但从长远来看，它会带来麻烦。不仅容易忘记，它还会降低代码灵活性。将来，你可能会想移除它，但一旦删除全局样式，依赖它的网站功能就会崩溃。 Delphi组件编写者指南关于《组件编写者指南》翻译的说明 1. 译文中粉红色的部分，是译者认为原文有错误的地方，我已改过，只是用粉红色作了标记； 2. 对于有关“参看”的各章节的页码，我也没有建立页码的关联，因为麻烦，所以只是用原书中的页码值，同时用蓝色加以标记，可以直接删除； 3. 由于原书只分章，没有分节。阅读起来不便。所以，我加了章节的编号，这样更清楚。 4. 书中的“第V部分的其余章节”没有真正的对应部分，所以照译出 我个人建议根本不要在 如果你仍然坚持使用它（正如Tailwind文档所说，例如“覆盖第三方库中的样式”），至少创建类。 使用 但是… 锚元素是打破这条规则的诱人例外，因为为每个 一种替代方案是创建一个围绕锚点（或Nuxt中的 事实上，使用 如果你100%确定需要全局元素样式，可以使用 教训二：Tailwind类定义过长/重复的根本原因是代码设计不当。 使用Vue等现代JavaScript框架，可以创建小型可重用组件，并将其组合构建复杂的解决方案。 上面的按钮示例可以改写成： 这样，重复的代码就消失了。 看到很长的类链，总是让我觉得元素承担了过多的职责。最好的方法是退一步，重新思考导致这个问题的代码设计。 我的经验是，只需少量Tailwind类即可创建美观的设计。如果需要更多样式，通常不应该全部堆积在一个元素上。这与创建一个大型组件（或类）来做所有事情类似，最终需要停止添加更多行并开始分解事物。 在最坏的情况下，应该能够将视觉要求高的CSS元素封装到单独的组件中，以最大限度地减少所需的交互量。或者，可以使用现成的Tailwind组件库。
div {
@apply m-auto text-center text-white;
}
tailwind.css文件中，这在2023年看起来或许是个好主意，但现在却成了问题。@apply。
tailwind.css中使用@apply（如果我有时间和精力的话，会从所有项目中移除它）。.my-cool-css-class是可以接受的，因为你必须将其附加到要设置样式的元素上。这样，每个人（包括未来的你）都能看到它，并在需要时找到它的定义。元素添加类属性很繁琐。@apply指令仍然是解决这个问题最常见的方案。@apply，但这应该始终是有充分理由的决定。
