UnoCSS 的快在于按需生成：仅对实际出现的类名触发纯函数映射，绕开正则匹配、AST 遍历与冗余剔除；uno.css 体积近乎为零，因不预生成规则，而是依 theme、rules 和 content 配置动态产出唯一 CSS 声明。
UnoCSS 的 CSS 按需生成到底快在哪儿
它不解析 HTML 模板，也不扫描源码字符串——而是靠「原子类名到 CSS 规则」的纯函数映射，在构建时或运行时，只对实际出现的类名触发生成。快的本质不是“编译器优化”，而是彻底绕开了传统原子化框架（如 Tailwind）的正则匹配 + AST 遍历 + 冗余规则剔除整套流程。
为什么 uno.css 文件几乎为零体积，且无需 @apply 或预定义变体
UnoCSS 默认不预生成所有可能的原子类，而是用 theme 和 rules 定义“生成协议”：一个类名（如 text-[#3b82f6]）进来，extractor 提取后，matcher 匹配到对应 rule，再由 generator 输出唯一一条 CSS 声明。没有预设断点、颜色语义或响应式前缀的硬编码膨胀。
-
text-red-500不是内置规则，而是通过theme.colors.red['500']查表 + 插值生成 -
md:grid-cols-3不依赖预置媒体查询块，而是variant动态包裹生成器，仅当该组合真实出现才产出对应@media块 - 自定义
rule可直接返回{ handle: 'font-mono', style: 'font-family: ui-monospace, SFMono-Regular;' }，无 DSL 解析开销
常见踩坑：content 配置漏写、attributify 与 shortcuts 的执行顺序问题
UnoCSS 不自动读取所有 .vue 或 .tsx 中的 class 字符串——必须显式配置 content glob 列表，否则开发时热更正常但构建产物缺失样式；而 attributify（如 bg="blue-500 hover:blue-600"）和 shortcuts（如 btn: "px-4 py-2 rounded bg-blue-500"）若定义顺序错乱，会导致 shortcut 中的 hover: 被 attributify 提前拆解，破坏嵌套逻辑。
- 务必确认
content包含所有模板路径，例如['src/**/*.{vue,ts,jsx}']，不能只写src/**/* -
shortcuts应放在attributify之后，否则 shortcut 内部的变体（如hover:xxx）不会被识别为有效变体 - 动态类名拼接（
class={`${base} ${isPrimary ? 'bg-blue-500' : 'bg-gray-300'}`）默认无法提取，需配合dynamicRules或显式extraProps声明
VS Code 插件提示不准、HMR 样式丢失，其实和 preprocess 阶段无关
UnoCSS 的 VS Code 插件依赖 unocss-config.ts 导出的完整配置对象做静态分析；如果 config 里用了动态 import 或环境变量分支（如 process.env.NODE_ENV === 'dev' ? ... : ...），插件无法执行 JS，就会退化为默认规则集。同理，Vite HMR 失效往往是因为 transformerDirectives（如 @apply 支持）未启用，或 preflights 开启了但未配 presets 导致重置样式未注入。
立即学习“前端免费学习笔记（深入）”；
- 插件要求 config 必须是同步导出，避免
await、fs.readFileSync或条件判断 - HMR 下 class 新增不生效？检查是否启用了
transformerDirectives（用于处理@apply）或transformerVariantGroup（用于group-hover:[&_span]:text-red-500） -
preflights默认开启，但若没引入@unocss/preset-uno，基础重置样式不会注入，导致按钮等元素样式异常
真正影响速度的从来不是“能不能生成”，而是“要不要生成”。UnoCSS 把决策权交还给类名本身，代价是配置稍显琐碎、动态场景需额外声明——这恰恰是它快得不突兀的原因。
