我不推荐 Tailwind CSS
Tailwind CSS 让前端开发者意见分裂：一些人认为它的实用优先类是驯服庞大、混乱样式表的优雅方式，也能让组件自包含，并便于在大型团队中复用。批评者则认为它让标记臃肿、掩盖语义、削弱结构与设计的分离，最终只是重新抽象了一层 CSS，但你仍然得理解底层语言。许多人得出的结论是，“正确”的选择高度依赖上下文——项目规模、团队技能和工具链——而现代原生 CSS、CSS Modules、BEM 或 UI 库等替代方案，往往更适合长期维护。
总体语气
- 讨论高度两极分化，而且重复了过去关于 Tailwind 的争论；很多人称之为挑剔细节式争论（bikeshedding）。
- 一些人指出 Tailwind 持续流行，说明它确实解决了真实问题；另一些人则认为它的传播是前端领导力薄弱或“slop”的表现。
Tailwind 的被感知优势
- 加快实现速度，尤其适合不想设计 CSS 架构或命名方案的开发者。
- 实用类让组件/页面自包含；修改不太会在别处引发级联回归。
- 可在 Tailwind 配置中集中设计一致的设计系统（颜色、间距、圆角、暗色模式等），再通过工具类复用。
- 通过避免分裂的 BEM 约定和 CSS “意大利面条”式代码，它在大型团队和代码库中表现良好。
- 很容易在项目之间复制/粘贴元素，并让它们看起来完全一致。
- 自动补全、IDE 工具和 AI 辅助让这些类名易于记忆和使用。
主要批评
- 标记变得嘈杂且难以阅读；class 属性编码了一种迷你语言，而不是使用语义化类名。
- 打破或模糊了“结构 vs 样式”的分离；感觉像是在倒退回内联样式。
- 除了 CSS 之外，还必须学习 Tailwind 的词汇；有经验的 CSS 开发者表示这反而拖慢了他们。
- 级联/优先级问题（例如冲突的工具类）削弱了“局部推理”，于是又催生了 tailwind-merge 之类的附加工具。
@apply的使用存在争议：有人认为为了保持可控它是必要的，另一些人则说这违背了 Tailwind 的目的。- 鼓励临时性的单次取值（
p-[13px]、混用色阶），因此一致性仍然取决于开发者自律。
CSS、组件与替代方案
- 一些人认为 CSS 本身（以及 HTML 的模型）才是根本问题；Tailwind 只是众多务实应对方式之一。
- 另一些人更偏好现代 CSS 搭配变量、嵌套、作用域样式、CSS Modules 或 BEM，通常再结合组件框架一起使用。
- 有些人会拆分职责：用 CSS 或设计系统处理 token 和语义；只在布局/排版上使用类似 Tailwind 的工具类。
- 少数人指出，随着 LLM/agent 生成 CSS，Tailwind 的主要优势（快速手写）未来可能没那么重要。
背景与“合适工具”观点
- 许多人最终认为是否适合取决于上下文：它适合大型团队、原型以及工具类需求重的 UI；对于小型、设计良好、组件范围明确的 CSS 代码库来说，吸引力就没那么强。