在 v4 Oxide 引擎落地前,Tailwind 整套流程依托 Node.js + PostCSS 运行,存在四大底层先天短板,无法通过业务配置、插件优化彻底解决。
单线程 JS 执行,多核 CPU 完全闲置
Node.js 主线程单事件循环模型,模板扫描、类名提取、CSS AST 生成、样式拼接、后处理全部串行执行;即便 CPU 拥有 8/16 核心,编译全程仅占用 1 个核心算力,万文件大型项目算力资源严重浪费。
PostCSS 多层插件串行,重复遍历 CSS AST
v3 完整编译链路包含多层串行插件:tailwindcss 核心插件 → 自动前缀 autoprefixer → CSS 压缩 cssnano,每一层插件都会完整遍历一遍 CSS 抽象语法树,字符串序列化/反序列化重复消耗内存与 CPU;单次全量构建会产生 3~5 次完整 AST 遍历。
模板扫描与样式生成割裂,无全局增量缓存
模板文件扫描(glob 遍历、正则匹配提取原子类)与样式生成分属两套独立逻辑,无统一内存缓存池:
- 全量构建时重复读取全部模板磁盘文件;
- 热更新仅能做简易文件哈希对比,无法复用上次扫描的类名集合;
- 未使用原子类无法全局标记,每次构建需完整重算全部可用样式。
JS 内存模型开销高,海量样式易内存溢出
JavaScript V8 堆内存存在 GC 周期性停顿,当项目存在数万条原子样式时,字符串拼接、AST 节点对象会持续堆积内存,大型 Monorepo 长期开发易出现内存持续上涨、进程卡顿甚至崩溃。