Tailwind CSS v3与v4生产体积无本质差异，关键取决于JIT是否生效、content是否扫全、safelist是否合理；配置错误时两者均输出近2MB全量CSS，须通过TAILWIND_MODE=build强制构建并用grep验证类名裁剪效果。
Tailwind CSS v3 和 v4 的生产环境体积差异，**不取决于引擎语言（JS vs Rust）或是否用了 Lightning CSS，而只取决于 JIT 是否真正生效、content 是否扫全、safelist 是否合理**。v4 默认不会比 v3 更小——配置出错时，两者都会输出近 2MB 全量 CSS。
如何用同一套项目对比 v3 和 v4 的真实产出体积
别信本地 npm run dev 显示的 CSS 大小，它对两者都无意义。必须走强制生产构建流程，生成真实 dist/output.css 后再比：
- 统一用
TAILWIND_MODE=build npx tailwindcss -i ./src/input.css -o ./dist/output.css --minify构建，禁用任何构建工具封装逻辑 - v3 项目确保
postcss.config.js中已移除purge字段，只保留content数组 - v4 项目必须删掉所有
@tailwind指令，改用@import "tailwindcss"，且postcss.config.js中移除tailwindcss()插件 - 构建前清空
dist/并确认tailwind.config.js中content路径完全一致（例如都写src/**/*.{js,jsx,ts,tsx}，不带./前缀）
为什么直接看文件大小会误判
文件系统显示的 output.css 大小不是关键指标——v4 的 CSS 可能略小几 KB，但若漏扫了 dark: 类，实际线上渲染时会因 fallback 行为引入更多内联样式或 JS 修复逻辑，整体交付体积反而更大。
- 用
grep -o "text-lg" ./dist/output.css | wc -l和源码中出现次数对比：两者都应接近（比如源码出现 127 次，CSS 里有 125 个），差太多说明 JIT 未生效 - 检查冷门类是否残留：
grep -o "bg-gradient-to-r" ./dist/output.css—— 若命中，说明 content 没扫到用该类的文件，v3/v4 都会崩 - v4 的
@theme声明会生成额外的 CSS 自定义属性规则（如--color-primary-500），但体积增加通常 --tw- 变量重复，说明@theme块位置不对或被多次 import
v4 在体积控制上容易被忽略的陷阱
v4 的自动 content 扫描只在 Vite + @tailwindcss/vite 下默认启用，且仅查 ./src/**/*.{js,jsx,ts,tsx}；一旦项目含 .astro、.svelte 或服务端模板（如 views/*.html.ejs），就必须显式写 content 字段——否则这些路径下的 class 全丢，你只能靠宽泛 safelist 救火，体积立刻反弹。
立即学习“前端免费学习笔记（深入）”；
-
tailwind.config.js被删或留空 → v4 不报错，但hover:、group-hover:等变体类几乎全失效，导致你不得不加/^hover:/这种高危正则进safelist - 继续保留
postcss.config.js中的tailwindcss()插件 → 与 v4 的 Oxide 引擎冲突，可能跳过 purge 步骤，输出全量 CSS - 用
@import "tailwindcss/theme"代替@theme块 → v4 不识别，主题变量不注入，JIT 无法推导色阶，被迫生成更多冗余类来覆盖缺失值
真正影响体积的从来不是版本号，而是你有没有让 JIT 看到所有 class 出现场景。v4 给了更快的构建和更灵活的主题控制，但没给你免检的 content 配置权——漏一个路径，就少一组类；多一条宽泛正则，就多几十 KB。
