tailwind 样式体积过大导致 lighthouse 评分低的根本原因是 content 字段配置不全，jit 模式仅按显式声明路径静态分析字面量 class，漏配路径、未覆盖 mdx、动态 class 未兜底或未启用生产构建裁剪均会导致冗余样式注入首屏。
Tailwind 默认生成的 CSS 会严重拖垮 Lighthouse 的“消除渲染阻塞资源”评分，根本原因不是它太重，而是你没告诉它哪些类真正被用到了——content 字段漏配、路径不全、动态 class 没兜底，都会让几百 KB 甚至 MB 级的未用样式强行进首屏。
tailwind.config.ts 的 content 字段必须全覆盖且显式声明
这是唯一决定 Tailwind 是否能按需提取样式的核心配置。JIT 模式不会扫描整个项目，只看你列出来的路径里有没有字面量 className 出现。
- Next.js App Router 必须同时包含：
./app/**/*.{js,ts,jsx,tsx}和./src/components/**/*.{js,ts,jsx,tsx}；漏掉layout.tsx或loading.tsx，dark:、group-hover:这类变体类大概率消失 - 用了
.mdx（比如博客页或文档组件），必须显式加：./src/**/*.mdx；否则里面写的text-blue-500直接被当成死代码干掉 - 避免深度嵌套 glob，如
./**/*.tsx在某些 Node 版本下失效；推荐分层写死：./app/**/*.{js,ts,jsx,tsx}、./components/**/*.{js,ts,jsx,tsx}
动态拼接的 class 名（如 className={`p-${size}`）无法被静态分析
Tailwind 的 PurgeCSS 机制只认字面量，遇到模板字符串或变量拼接就跳过。上线后可能出现按钮没 padding、文字颜色丢失等事故。
- 不要靠
safelist硬加['p-2', 'p-4', 'p-6']——这会导致所有尺寸类回流，体积不降反升 - 优先改用
@apply封装成确定类名：@apply p-4 text-blue-600;写在.module.css或@layer里 - 若必须动态控制，用 CSS 变量 +
style替代：style={{ padding: sizeMap[size] }}，把逻辑从 class 名转移到内联样式
构建命令必须走生产模式且带 --minify
开发时 npm run dev 看不到体积问题，因为 JIT 是内存中实时生成；真正裁剪只发生在生产构建阶段。
- 错误写法：
npx tailwindcss -i ./src/input.css -o ./dist/output.css→ 缺少--minify，且未设环境变量，Purge 完全不触发 - 正确写法（推荐）：
TAILWIND_MODE=build npx tailwindcss -i ./src/input.css -o ./dist/output.css --minify - Next.js 用户请确认
next build调用的是 Tailwind v4+ 的 PostCSS 插件（@tailwindcss/postcss），旧版 CLI 插件即使配了content也不会执行裁剪
验证裁剪是否真生效，别信文件大小数字
很多构建流程压缩了空白和注释，但冗余类还在。得看类名是否真的被删了。
- 在任意一个被
content覆盖的.tsx文件里加一行：className="bg-hotpink text-9xl"（这两个类 Tailwind 默认不提供） - 运行生产构建后执行：
grep -c "bg-hotpink" dist/output.css，结果应为0 - 如果返回非零，说明
content路径漏了、或有构建缓存干扰；删掉.next和out目录重跑next build
最容易被忽略的是：Tailwind 本身不慢，慢的是你告诉它“扫描范围”的动作没做对——路径差一条、MDX 后缀漏一个、环境变量带错，优化就归零。它不像 JS 那样能靠懒加载补救，CSS 阻塞是硬性的、不可绕过的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
