UnoCSS更快的根本原因是跳过AST解析，直接字符串扫描+正则提取，新增类响应仅1~2ms，HMR延迟约80ms；Tailwind需全量AST分析，常重跑整链，HMR达400ms+。
UnoCSS不解析AST，Tailwind必须解析
UnoCSS快的根本原因不是“优化得更好”，而是它压根不走Tailwind那条路：Tailwind CSS（含JIT）必须用PostCSS解析整个源码AST，再遍历节点提取class属性值、匹配规则、生成CSS；UnoCSS跳过AST，直接对文件内容做字符串扫描+正则提取——比如在.vue里看到text-red-500四个字符连续出现，就触发生成对应CSS，中间不建语法树、不走PostCSS pipeline。
这导致两个实际差异：
- 新增一个类，UnoCSS响应在1~2ms内；Tailwind JIT常需重跑整块CSS生成链
- 大型项目中，UnoCSS的HMR延迟稳定在
~80ms；Tailwind在复杂组件下常卡到400ms+
UnoCSS的“按需”是真跳过，Tailwind的“按需”仍要扫全量
Tailwind的JIT所谓“按需”，本质是content配置指定路径后，对这些路径下所有文件做全量AST扫描——哪怕某个.md文件里只有一行class="text-sm"，它也要把整个Markdown AST parse一遍。UnoCSS默认不依赖content glob扫描，而是靠transformerDirectives和extractor插件，在Vite加载资源时实时拦截.vue/.tsx等模块的内容字符串，只提取模板中字面量出现的类名。
这意味着：
立即学习“前端免费学习笔记（深入）”；
- 没写的类，连内存里都不会存在，更不会进构建产物
- 动态拼接类名（如
clsx('text-red-500', isActive && 'font-bold')）能被@unocss/extractor-regex捕获前半段；Tailwind需配safeList或正则白名单，否则直接漏提 - 修改组件但未动类名，UnoCSS HMR几乎不触发CSS重建；Tailwind可能因AST diff机制重生成整块
加了@unocss/transformer-directives还快吗？
当你启用@unocss/transformer-directives支持@apply、@screen等指令时，UnoCSS确实会引入css-tree做轻量AST解析——但这仅限于CSS文件内部，且范围可控。而Tailwind的AST解析是贯穿HTML/JSX/Vue模板+CSS文件的全链路，无法规避。
实测数据（2024年基准测试，MacBook M1，1656工具类 + 等量@apply）：
-
unocss v0.58.5：平均328.39ms -
tailwindcss v3.4.1：平均798.42ms（慢2.52x）
也就是说，即使加上CSS指令支持，UnoCSS仍比Tailwind快一倍以上。
构建产物体积差异也源于生成逻辑
Tailwind即使JIT开启，也会预生成大量变体组合（如hover:scale-110、md:hover:scale-110），除非显式禁用；UnoCSS默认只生成模板中真实出现的变体——写了hover:scale-110才生成，否则完全跳过。这直接反映在包体积上：同等项目下，UnoCSS生产CSS比Tailwind JIT小12%–18%，节省主要来自未使用的状态变体与媒体查询组合。
真正容易被忽略的是：UnoCSS的uno.css不是普通样式表，它是运行时注入的占位符；删掉或提前加载会导致样式丢失——这个细节和性能无关，但一旦踩坑，问题现象像“样式不生效”，排查方向却完全不在速度上。
