tailwind 通过 postcss 插件按需生成 css：插件扫描 content 配置指定的源文件，静态提取硬编码类名，仅生成实际使用的样式规则，实现精准编译与体积优化。
PostCSS 插件如何让 Tailwind 只生成用到的类
Tailwind 的核心效率不来自“写得快”，而来自“编译得准”——postcss.config.js 中加载 tailwindcss 插件后，它会在构建或开发阶段扫描 content 配置里列出的所有源文件（如 ./src/**/*.{js,jsx,ts,tsx}），静态提取所有出现的类名，然后仅生成这些类对应的 CSS 规则。
这意味着：text-sm、text-lg、text-xl 不会全被塞进 CSS 文件；你只写了 text-lg，就只生成这一条规则。传统 CSS 框架打包时把整套样式表全塞进去，Tailwind 用 PostCSS 插件把它变成“按需索引+即时查表”。
- 必须确保
postcss.config.js包含require('tailwindcss')，否则插件链断开，Tailwind 不会运行 - 如果项目用 Vite/Next.js/SvelteKit，默认已集成 PostCSS，但依然要检查
postcss.config.js是否存在且内容正确 - Webpack 项目需手动确认
postcss-loader已启用，并在rules中正确引用该配置
为什么 content 路径漏一个文件，样式就直接消失
content 字段不是“建议扫描范围”，而是 Tailwind 唯一的类名来源。它不做运行时分析，也不解析 JS 变量或模板字符串里的类名——只读取你明确列出来的文件里硬编码的 class 或 className 值。
常见失效场景：
- 组件放在
./components/，但content只写了./src/**/*，漏掉路径 → 对应组件的类不生成 - 使用
.html模板（如 Astro、Svelte），但content没包含*.html后缀 → 类名被忽略 - 动态拼接类名，例如
className={`p-${size} ${isActive ? 'bg-blue-500' : ''}`→ JIT 无法静态推导size可能的值，这部分样式丢失
JIT 模式下，PostCSS 插件实际做了什么
Tailwind v3.0+ 默认启用 JIT，但 JIT 不是独立工具，它完全依赖 PostCSS 插件在构建流程中接管样式生成逻辑。插件在每次文件保存后触发重新扫描，对比新旧类名集合，增量更新 CSS 输出，而不是重建整个样式表。
这带来三个可感知变化：
- 热更新变快：改一个
class，CSS 重编译耗时从秒级降到毫秒级 - CSS 体积骤降：实测生产环境从 2.1MB → 42KB（取决于项目实际使用率）
- 不再需要
purge字段：v3+ 的content就是 PurgeCSS 的替代，purge配置项已废弃
容易被忽略的兼容性细节
PostCSS 插件行为高度依赖上下游环境是否对齐：
- Node.js 版本低于 16.14 时，某些正则或模块解析可能失败，导致
content扫描静默跳过部分文件 - VS Code 中 Tailwind CSS IntelliSense 插件也读取同一份
tailwind.config.js，如果content路径写错，编辑器补全会失效，但构建仍可能“碰巧”工作（比如依赖了旧缓存） - CI 环境中若未安装
tailwindcss作为 devDependency，PostCSS 插件加载失败，构建会输出空 CSS 文件，且无明确报错
最常出问题的其实是 content 路径没覆盖全部组件文件，尤其是 storybook、test 文件夹或独立的 UI 库目录——它们不参与主构建，但开发者会在这里写 demo，结果发现 demo 有样式、正式页面没有。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
