开源我们在 Tailwind CSS v4.0 上的进展
Tailwind CSS v4 的 alpha 开源重新点燃了围绕 utility-first 样式的争论：许多开发者赞赏 Tailwind 能加速 UI 开发、减少命名负担，并充当“你设计系统的 API”；批评者则认为它会产出冗长、难以维护的 HTML，并削弱传统 CSS 架构。v4 最突出的变化是转向 CSS-first 配置，通过新的 `@theme` 指令将设计 token 以原生 CSS 变量的形式暴露出来，即便长期的怀疑者也认为这是重大改进，更尊重现代 CSS 特性。其他值得关注的点包括新引擎带来的性能提升、独立 CLI 的计划，以及 Tailwind 如何与 `@scope` 等新标准和 Bootstrap、Svelte、原子 CSS 竞争者等替代方案共存的持续问题。
对 Tailwind CSS v4 / CSS-first 方法的总体反应
- 许多人欢迎转向 CSS-first 配置、将主题值作为 CSS 变量，以及
@theme指令。 - 批评者认为这修复了一个重大缺陷：过去 Tailwind 鼓励避免“思考 CSS”；v4 被认为更符合现代 CSS 架构、层叠和设计 token。
- 一些用户仍然希望有以 JS 为主的配置工作流，并担心会失去那种简单性。
可维护性、可读性与“查看源代码”
- 支持者认为 Tailwind 让大型、多年、多人协作项目更易维护：全局 CSS 冲突更少、重构更容易，而且样式与组件放在一起。
- 怀疑者说冗长的 utility class 字符串是“只写不可读”的，难以在 devtools 中调试，也不利于通过查看源码学习。
- 关于编译/打包后的输出是否能公平代表可维护性，存在争论；有人认为不能，另一些人则指出 Tailwind 自己的示例本来就像构建输出。
设计系统、命名与工作流
- 支持者把 Tailwind 看作“你设计系统的 API”，也是避免脆弱继承关系的一种方式。有人认为 utility class 能减少命名负担和意外耦合。
- 反对者认为“命名很难”被夸大了，可以通过 BEM、作用域 CSS 或 CSS modules 等约定解决。
- 多位评论者强调，Tailwind 最适合把大量 class 堆叠封装进组件里，而不是在每处都直接重复内联。另一些人警告不要使用
@apply，建议拥抱 utility 的“混乱”。
使用场景、替代方案与未来的 CSS 特性
- 有些人把 Tailwind 视为一种“快速把事情做完”的工具，它刻意牺牲语义纯洁性和经典的“CSS Zen Garden”理想。
- 也有人认为，对于主题化、第三方覆盖，以及高度可定制的 white-label 产品，传统 CSS 或组件库（Bootstrap、DaisyUI 等）可能更合适。
- 讨论还涉及即将到来的原生特性，例如
@scope加上 CSS 变量，是否最终会减少对 utility 框架的需求；时间表和跨浏览器支持被认为是限制因素。
工具链、CLI 与生态系统
- 新引擎的独立 CLI 受到期待；不过维护者表示，为了保留 JS 插件生态，它很可能仍会内嵌 Node。
- 一些人对持续依赖 Node 表示遗憾，尤其是在基于 Rust 的技术栈中，并希望独立 CLI 能提供更好的插件支持。
AI 与学习
- 有评论者指出，像 GPT-4 这样的模型在处理新的 Tailwind 语法时表现不佳；有人建议使用 RAG，但认为它不如模型本身具备强大的原生知识。
- 在学习和最佳实践方面，人们推荐官方文档、视频播放列表，以及基于组件的结构，而不是原始、重复的 class 列表。