Tailwind 的 JIT 模式只编译源码中显式写出的 class 字符串，通过 AST 分析提取并动态生成对应 CSS 规则；不支持运行时拼接、需手动写出响应式/状态变体、safelist 应精准而非泛化、配置变更需重启或依赖生态 HMR。
Tailwind 的 JIT 模式到底编译什么
JIT 模式不是“实时生成 CSS 文件”，而是按需解析源码中的 class 字符串，只生成实际用到的工具类规则。它跳过了传统扫描全项目 HTML/JSX 的步骤，改用 AST 分析（如 PostCSS 插件 + 正则 fallback）提取 class 名字，再动态构造对应 CSS 声明。
关键点在于：JIT 不依赖文件路径或构建时静态扫描，而是紧贴你写的 class 字符串本身——哪怕写在 className={dynamicClass} 里，只要字符串是静态可分析的（比如模板字面量、字符串拼接常量），JIT 就能捕获。
- 支持
tw`text-red-500 bg-blue-200`（通过tailwindcss-jit或@tailwindcss/vscode插件增强） - 不支持运行时拼接：
className={`text-${color}-500`}，这种会被忽略，除非你显式用addComponents或safelist - 默认禁用
@apply的嵌套展开（性能代价高），需手动开启experimental.optimizeUniversalDefaults
为什么开了 JIT 还有未生成的 class
常见错误现象：text-xl 生效了，但 md:text-2xl 或 hover:underline 没效果，浏览器里查不到对应 CSS 规则。
根本原因不是 JIT 失效，而是这些变体（responsive / state / dark mode）没被“显式触发”——JIT 默认只收集基础 class，响应式前缀和伪类需要你在源码中真实写出完整形式，不能靠配置“推断”。
立即学习“前端免费学习笔记（深入）”；
-
md:text-2xl必须出现在源码里，写成class="md:text-2xl"或tw`md:text-2xl`，不能只写text-2xl然后指望 JIT 自动补 md 版本 -
hover:underline同理，class="hover:underline"要真实存在；group-hover:underline还需确保父元素有group类 - 暗色模式类如
dark:bg-gray-800需要你在tailwind.config.js中启用darkscheme: 'media'或'class'，且 class 字符串必须带dark:前缀
JIT 模式下 safelist 怎么写才不冗余
safelist 不是兜底方案，而是给 JIT 提供“无法静态分析”的 class 白名单。滥用会抵消 JIT 的体积优势，甚至让 CSS 变得比 AOT 还大。
正确做法是只填真正动态的、不可预测的 class 组合，而不是把所有可能的变体都列进去。
- 错：写
['text-*', 'bg-*']—— glob 匹配会让 JIT 生成所有 text-*/bg-*，失去按需意义 - 对：用正则精确匹配，比如
[/^text-(red|blue)-(500|600)$/, /^bg-opacity-\d+$/] - 更优：结合
content配置 + 注释提示，例如在 JSX 里写{/* @safelist text-emerald-400 */}，部分插件能自动提取 - 注意：safelist 中的 class 仍受
corePlugins和variants控制，比如禁用了preflight，safelist里的重置类也不会生成
开发时 CSS 热更新慢？可能是 JIT 的 watch 策略没对上
JIT 默认监听 content 配置里列出的所有文件，但不会监听 tailwind.config.js 的变更——改了 theme 或 plugins，必须重启构建进程。
另一个隐蔽问题是：某些编辑器（如 VS Code）保存时触发了临时文件写入（.swp、~ 结尾），导致 PostCSS 重复编译或卡住。
- 确保
content路径是精确 glob，避免写./src/**/*这种太宽泛的，会拖慢文件系统监听 - 在
tailwind.config.js中加watch: true（v3.4+）可启用细粒度文件监听，但仅限 CLI 场景；Vite/Webpack 用户应优先用各自生态的 HMR 集成 - 如果用 Vite，确认已安装
@tailwindcss/vite插件，它会接管 CSS 生成逻辑，绕过 PostCSS 的 watch 瓶颈 - 遇到热更新延迟，先
console.log一下tailwind.config.js是否被重新 require —— 很多时候问题出在配置缓存，而非 JIT 本身
JIT 的核心约束始终是：它只信任你写死在源码里的 class 字符串。任何靠运行时逻辑、第三方库注入、服务端模板拼接出来的 class，都得靠 safelist 或 addUtilities 显式声明，这点容易被忽略。
