根本原因是PostCSS插件链阻塞：未启用JIT、content路径遗漏、手动postcss.config.js干扰插件顺序，或动态类拼接导致扫描失效；验证需见终端“Using JIT”提示及新类实时生效。
Tailwind CSS 在 Next.js 项目中启动慢、热更新卡顿，根本原因不是 Tailwind 本身慢，而是 PostCSS 插件链阻塞了 CSS 处理流程，尤其在未正确启用 JIT 或插件顺序/配置有误时，构建会退化为全量扫描 + 全量生成。
确认 JIT 是否真在 Next.js 中生效
Next.js 13+ 默认集成 Tailwind，但不等于 JIT 就一定开着。很多项目仍沿用旧版 tailwind.config.js 配置，或被遗留的 purge 字段干扰（v3 已废弃）。
- 检查
tailwind.config.js是否含mode: 'aot'或purge:字段 —— 有则删掉，JIT 模式下只认content -
content必须显式覆盖所有含 class 的文件，例如：['./app/**/*.{js,ts,jsx,tsx}', './components/**/*.{js,ts,jsx,tsx}']；漏掉app/layout.tsx或components/Navbar.tsx就会导致类名“消失” - 终端启动时必须看到
Using JIT (Just-In-Time) mode提示，没这行就说明 JIT 没激活（常见于手动加了postcss.config.js覆盖了 Next.js 默认配置）
PostCSS 插件顺序与 Next.js 冲突点
Next.js 自带 PostCSS 支持，若你在项目根目录手动创建 postcss.config.js，它会完全接管处理逻辑，而默认插件顺序可能破坏 JIT 流程 —— 比如把 cssnano 放在 tailwindcss 前，会提前压缩掉尚未生成的 utility 类。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- Next.js 官方推荐：**不要写
postcss.config.js**，除非你明确需要自定义 autoprefixer 或 cssnano；JIT 和 tailwindcss 插件由框架自动注入且顺序正确 - 如果必须自定义，确保
tailwindcss是第一个插件，autoprefixer第二，cssnano（仅生产）放在最后 - 禁用
cssnano的discardComments或normalizeWhitespace，它们会干扰 JIT 的 class 名匹配（尤其动态类场景）
动态 class 拼接导致 JIT “看不见”
JIT 扫描器只识别字符串字面量，className={`text-${size}-500`} 这种写法会让 text-sm-500 等组合类彻底丢失 —— 不是编译慢，是压根不生成。
立即学习“前端免费学习笔记（深入）”；
- 静态 fallback：用三元或对象映射代替拼接，例如
className={size === 'sm' ? 'text-sm-500' : 'text-lg-500'} - 白名单兜底：在
tailwind.config.js的safelist中声明高频动态值：safelist: [/text-(sm|lg|xl)-500/, /bg-\[.*\]/] - 避免在
content扫描路径外写 JSX —— 比如把组件抽到lib/utils.ts里返回 class 字符串，JIT 扫不到
真正卡顿的根源往往不在 Tailwind，而在 PostCSS 插件链是否被意外打断、content 是否漏掉关键路径、以及动态类是否触发了 JIT 的盲区。改完配置后，务必用一个全新类（如 bg-[#0ea5e9]）验证是否实时生效 —— 这比看构建时间更可靠。
