npm 装了八年 Tailwind，今天它的配置文件彻底姓 CSS 了

每次改个颜色要去翻 tailwind.config.js，这件事前端工程师忍了八年——今天 Tailwind v4 用一个 @theme 块把整个配置彻底搬进了 CSS 文件，再也不用在 JS 和 CSS 之间来回跳了。

问题的根在哪里

Tailwind v3 的配置是纯 JS 文件，配色、间距、字体全写在一个 theme: {} 对象里。你改一个颜色要去 JS，改一个断点也要去 JS，设计师给你的 Figma token 要手动转成 JS 对象再复制进去。更麻烦的是，这些值一旦写进 JS，就只能通过 Tailwind 的工具类来用——想直接在 CSS 里引用？对不起，JS 变量不是 CSS 变量，用不了。

@theme 把配置彻底 CSS 化了

Tailwind v4 引入了 @theme 指令，配置直接写在 CSS 文件里，变成真正的 CSS 自定义属性：

@import "tailwindcss";

@theme {
  --color-brand: oklch(0.72 0.16 250);
  --font-display: "Inter Tight", sans-serif;
  --spacing-container: 2rem;
}

这三个值现在同时是两个东西：既是 Tailwind 的工具类变量（bg-brand、font-display、p-container），又是标准 CSS 自定义属性，可以在任何 CSS 规则、inline style、甚至 JS 的 getComputedStyle 里直接读。配置和样式终于在同一个地方了。

Rust 引擎把性能从秒级压到毫秒级

这不只是语法变化，引擎也换了。Tailwind v4 的 Oxide 引擎用 Rust 重写，替代了原来 PostCSS + JS 的管道。一个 500+ 组件的真实 Next.js 项目，性能数据是这样的：

• 冷启动：12.3s → 1.8s，快了 6.8 倍
• 开发服务启动：4.2s → 0.8s，快了 5 倍
• 热更新：340ms → 12ms，快了 28 倍
• 产物大小：48KB → 31KB，缩减 35%
• 内存占用：180MB → 45MB，省了 75%

这些数字来自一个生产项目的实测（practical.dev，2026 年 7 月）。大项目里 Tailwind 以前”还能接受”的构建时间，现在直接变成了”感知不到”。

配色终于用上了人眼认识的方式

v4 把默认色域从 HSL 换成了 OKLCH。HSL 的问题是数值上的亮度和人眼实际感知的不一致——HSL 里 50% 亮度的蓝和黄，实际看起来亮度差很多。OKLCH 的 L（Lightness）是真的在描述人眼感知，同样 62% 亮度的蓝和绿，看起来就是一样亮。配合 @theme，配色体系在 CSS 层面就和人眼认知对齐了。

迁移成本在哪里

Utility 类名（flex、grid、text-sm）全部不变，模板几乎不用改。迁移的主要工作在两处：一是把 tailwind.config.js 里的 theme: {} 内容搬到 @theme {} 里，把 extend: {} 改成直接在 @theme 里加变量；二是检查有没有插件还没支持 v4 的——插件是迁移的主要风险点。大多数项目迁移一个下午能完成。

下一步

如果你的项目还在用 v3，可以先用 npx tailwindcss@latest 装上，然后跑官方迁移工具把 tailwind.config.js 转成 @theme 格式，先在小分支试跑一圈，确认组件没问题再合入。正在开新项目的，直接上 v4，配置文件从第一天就在 CSS 里，团队里任何人改配色再也不需要懂 JS。