Tailwind CSS v4 是框架自诞生以来最大的一次架构变革。它不再是一个 PostCSS 插件，而是转变为一个原生 CSS 引擎，配置文件也彻底告别了 JavaScript，迁移到了纯 CSS 配置。这篇文章深入解析这些变化背后的设计考量以及实际迁移路径。
从 PostCSS 到原生 CSS 引擎
在 v3 及更早版本中，Tailwind 依赖于 PostCSS 的插件机制来扫描源码、生成原子类。这种方式虽然灵活，但存在几个根本性的问题：PostCSS 需要 Node.js 运行时，与现代构建工具的集成常有摩擦，且扫描过程的速度受限于 AST 遍历的开销。
v4 重写了核心引擎，用 Rust 编写了扫描器和生成器，通过 npm 发布为原生二进制模块。带来的直接收益是：
- 构建速度提升 5-10 倍（大型项目测试数据）。
- 不再依赖 PostCSS，可以与任何构建工具集成。
- 支持增量构建，只重新生成变更的部分。
CSS 优先的配置方式
v4 最直观的变化是放弃了 tailwind.config.js，改用纯 CSS 进行配置：
/* tailwind v4 — CSS 优先配置 */
@import "tailwindcss";
@theme {{
--color-primary: #3b82f6;
--color-secondary: #8b5cf6;
--font-size-heading: 2rem;
--spacing-gutter: 1.5rem;
}}
这与现代 CSS 的发展方向一致——CSS 自定义属性（CSS Variables）已经成为前端工程化的核心基础设施。将主题配置放在 CSS 层，意味着可以在任何 CSS 上下文中使用这些变量，而不是局限在 Tailwind 的工具类中。
新的变体系统
v4 重新设计了变体（variants）的实现方式。在 v3 中，每个变体（如 hover:、dark:、md:）都会在编译时展开为独立的 CSS 规则。v4 转而使用更高效的原生 CSS 嵌套和 :where() 选择器来减少输出体积。
一个重要的新特性是任意值变体：
<!-- v4 支持任意值变体 --> <div class="[@media(hover:hover)]:opacity-100"> ... </div>
这意味着不再需要等待框架更新才能使用新的 CSS 特性，任何有效的 CSS 媒体查询或选择器都可以直接在类名中使用。
迁移路径
从 v3 迁移到 v4 需要注意以下几点：
- 配置文件迁移：将
tailwind.config.js中的主题配置转换为@theme块。官方提供了自动迁移工具。 - 插件兼容性：旧的 PostCSS 插件可能需要重写。大多数官方插件已更新，社区插件需要逐个检查。
- 类名变更：大部分工具类名称保持不变，但有一些细节变更（如
shadow-{color}现在是内置功能）。 - 构建流程：如果项目使用 PostCSS 集成，可以选择切换到 v4 的独立 CLI 或 Vite 插件以获得最佳性能。
对于新项目，建议直接使用 v4。对于现有的大型项目，可以保持 v3 直到有明确的迁移需求，因为 v3 仍然在维护中。
Tailwind v4 的架构升级体现了 CSS 工具链的一个重要趋势：工具从"提供一套约定"转向"扩展原生 CSS 的能力"，而不是创建另一层抽象。