Tailwind CSS体积过大主因是content路径未配全导致JIT退化为全量输出；需覆盖所有含class文件（如app//、pages//）、为动态类配置safelist正则、并通过生产构建验证扫描是否生效。
content路径没配全，JIT就形同虚设
Tailwind生成2MB+ CSS，99%是因为content字段漏掉关键路径，导致JIT退化为全量输出。它不报错，只是安静地保留所有类。
- Next.js项目必须同时包含
app/**/*.{js,ts,jsx,tsx}和pages/**/*.{js,ts,jsx,tsx}，否则dark:、group-类大概率丢失 - 写
./src/**/*.{ts,tsx}会漏掉.jsx文件；写src/App.tsx单个文件，则子组件里的text-red-500根本不会被扫描到 - Vite/Next.js对
./src/**这种带点前缀的路径解析不一致，统一用src/**/*.{js,jsx,ts,tsx,html} - SSR或静态生成的模板（如
data/**/*.mdx、views/**/*.html.ejs）也得加进content，否则服务端渲染出的class会被当“死代码”删掉
动态类名不兜底，上线就丢样式
className={`text-${color}-500`}这种写法，JIT压根不识别——它只匹配字面量字符串，不执行JS，也不猜变量值。
- 优先改用
@apply封装：在.btn-error { @apply text-red-500; }里定义，再把该CSS文件路径加进content - 必须用动态拼接时，在
tailwind.config.js的safelist里写精确正则，例如/^text-(red|blue|green)-500$/，结尾加$防误匹配 - 避免
/^text-/这种宽泛正则，它会保住全部text-类，等于放弃tree-shaking -
md:text-lg和text-lg是两个独立类，safelist里只写后者，前者仍会被删
没走生产构建，验证全是假象
npm run dev正常≠生产正常。开发服务器是JIT实时生成，完全不依赖content扫描；而npm run build全靠它。
- 验证必须强制走生产流程：
TAILWIND_MODE=build npx tailwindcss -i ./src/input.css -o ./dist/output.css --minify - 人工注入冷门但合法类，比如在某个被
content覆盖的文件里加className="bg-hotpink" - 构建后运行
grep -o "bg-hotpink" ./dist/output.css：非空说明JIT没跑，还在全量打包；为空说明扫描已启动 - 再用
grep -o "text-lg" ./dist/output.css | wc -l对比源码中出现次数，显著减少（比如120→8）才是真生效
@apply不是万能解药，路径和嵌套都有限制
用@apply抽离高频类组合确实能缩短HTML体积、间接减小CSS输出，但它本身有硬约束。
立即学习“前端免费学习笔记（深入）”；
- 自定义类所在的CSS文件路径必须明确加入
content，否则JIT根本不会生成对应工具类规则 -
@apply不支持嵌套另一个@apply，写@apply btn-primary会报错Cannot resolve @apply for - 命名别过度抽象，像
.card-variant-3-sm反而增加维护成本，优先用.card+ 变量控制变体 - 框架组件库（如
react-datepicker）的class不在你源码里，要么加进safelist，要么显式引入其node_modules路径（慎用，易反弹体积）
content路径是否真实覆盖所有class来源、safelist是否用正则精准兜住动态类、以及验证是否绕开了开发服务器的假象——直接看生产构建输出。 
