前两篇已经回答了两个问题为什么 CSS 工程会从 Sass、CSS Modules、CSS-in-JS 走到 Tailwind以及原子化 CSS 为什么不等于“把样式随便堆在 HTML 上”从这一篇开始主线转向 Tailwind 的内部机制。如果把 Tailwind 只理解成“一套 class 名字表”后面的扫描、性能、JIT 和源码阅读都会显得零散更准确的理解是Tailwind 是一个构建期 CSS 编译器开发者在源码里写flex、px-4、hover:bg-slate-900编译器在构建阶段把这些字符串收集出来再生成浏览器能执行的 CSS。先把 Tailwind 看成编译器浏览器不认识 Tailwind浏览器只认识 HTML、CSS 和 JavaScript页面最终生效的不是hover:bg-slate-900这个“概念”而是编译出来的 CSS 选择器和声明.hover\:bg-slate-900:hover{background-color:var(--color-slate-900);}这意味着 Tailwind 的核心工作发生在浏览器运行之前它需要回答四个问题源码里出现了哪些可能的工具类 这些字符串哪些是真正的 Tailwind utility 每个 utility 应该生成什么 CSS 声明 这些 CSS 应该按什么顺序、放到什么层里输出这和 TypeScript 编译成 JavaScript 的感觉很像你写的是一种更适合开发者表达意图的输入工具链把它转换成浏览器能消费的输出区别在于Tailwind 的输入不是单独的.tw文件而是散落在 HTML、JSX、Vue、Svelte、MDX、后端模板和 CSS 入口中的普通文本。import tailwindcss是编译入口在 Tailwind CSS v4 中一个最小入口通常是这样importtailwindcss;这个入口不是“复制一份巨大 CSS 进来”它更像告诉构建工具这里需要启动 Tailwind 编译流程Tailwind 会根据入口 CSS、源码扫描结果、主题变量、内置 utility 和你声明的自定义规则生成当前项目真正用到的 CSS。所以import tailwindcss背后大致会展开成三类工作建立上下文读取入口 CSS、主题变量、source 配置、自定义 utility 收集候选扫描项目源码找到可能是 class 的字符串 生成输出把有效候选编译成 CSS并按 layer 和排序规则写出理解这一点后再看 Tailwind v4 的 CSS-first 配置就不难了theme、utility、custom-variant、source不是零散语法它们都在影响同一个编译上下文。类名、候选类名和 CSS 规则不是一回事日常开发里我们会说“这个 Tailwind 类名是px-4”但从编译器角度看至少要分三层。class是 HTML 属性里的原始内容buttonclassrounded-md bg-blue-600 px-4 py-2 text-white hover:bg-blue-700Save/button候选类名是扫描器从文本中切出来的 tokenrounded-md bg-blue-600 px-4 py-2 text-white hover:bg-blue-700CSS 规则是候选通过解析后生成的结果.px-4{padding-left:1rem;padding-right:1rem;}.hover\:bg-blue-700:hover{background-color:var(--color-blue-700);}为什么要强调这个区别因为扫描器看到一个 token不代表它一定会生成 CSS比如源码里出现Save、button、is-active扫描器可能把它们当成候选但后面的 utility 解析器如果不认识就会跳过。这也是 Tailwind 可以使用“宽松扫描”的原因先尽可能便宜地找出可能相关的字符串再由更严格的规则生成阶段判断哪些有效。一个按钮的编译过程用一个具体例子串起来假设组件里有这段代码export function SubmitButton() { return ( button classNameinline-flex items-center rounded-md bg-emerald-600 px-4 py-2 text-sm font-medium text-white hover:bg-emerald-700 Submit /button ); }Tailwind 不需要执行这个 React 组件它只需要读取源文件文本找到里面完整出现的 class 字符串然后拆成候选inline-flex items-center rounded-md bg-emerald-600 px-4 py-2 text-sm font-medium text-white hover:bg-emerald-700接着候选会进入解析阶段px-4解析成左右 paddingbg-emerald-600解析成背景色hover:bg-emerald-700先拆出hover变体和bg-emerald-700工具类再把 CSS 选择器包上一层:hover。你可以把它想成一条很朴素的流水线class 文本 - 候选集合 - utility 解析 - theme token 查找 - selector 转义 - CSS 规则这条线就是后面几篇文章的骨架扫描机制关心“候选从哪里来”规则生成关心“候选怎么变成 CSS”性能优化关心“这条线如何少做重复工作”。为什么动态拼接会失败既然 Tailwind 的输入是源码文本那么一个非常重要的约束就出现了完整类名必须能被扫描器看见。下面这种写法在运行时能拼出字符串但构建期扫描器看不到完整的bg-emerald-600或bg-rose-600function Badge({ tone }) { return span className{bg-${tone}-600 text-white}Status/span; }对 Tailwind 来说源码里只有bg-、-600、text-white这些片段它不会执行 JavaScript也不会枚举tone的所有可能值因此背景色规则可能不会生成。更稳定的写法是把完整 class 放在 map 里const toneClass { success: bg-emerald-600 text-white, danger: bg-rose-600 text-white, neutral: bg-slate-600 text-white, }; function Badge({ tone }) { return span className{toneClass[tone]}Status/span; }这不是“最佳实践偏好”而是由编译模型决定的完整字符串出现在源码里扫描器才能收集编译器才能生成 CSS。JIT 的关键不是运行时而是按需生成很多人听到 JIT 会联想到运行时编译但 Tailwind 的 JIT 更适合理解为“构建期按需生成”它不会先输出所有可能的 utility再让浏览器下载一份巨大 CSS它会根据源码里实际出现的候选生成需要的规则。比如项目只用了text-sm和text-lg就没有必要输出所有字号工具如果没有用到bg-purple-950对应规则也不会出现在最终 CSS 中这个模型让 Tailwind 可以提供非常大的 utility 空间同时保持输出 CSS 相对可控。但按需生成也带来两个工程问题第一扫描必须足够准确否则会漏生成第二增量构建必须足够聪明否则每次保存都重新扫描和生成会拖慢开发体验。这正是后续文章要展开的内容。结尾读 Tailwind 的实现不要一开始就陷进全部语法细节先记住这一层模型Tailwind 源码扫描器 候选解析器 规则生成器 构建工具集成当你遇到source它影响的是扫描器的输入范围当你遇到hover:、md:、data-[stateopen]:它们影响的是候选解析和规则包装当你遇到 HMR 慢、构建慢、CSS 体积异常通常要回到扫描范围、候选数量、缓存失效和输出规则这些位置排查。下一篇我们继续往前走专门看 Tailwind 如何从源码中“看见”类名以及为什么纯文本扫描既高效又容易被动态拼接误导。
