最有效做法是让Tailwind只生成首屏用到的类并内联，其余异步加载；核心在于content字段全覆盖精确扫描路径、safelist按需写正则兜底动态类，构建后须验证CSS裁剪率≥95%且内联体积≤14KB。
直接内联 Tailwind 生成的全量 CSS 是最差选择——它通常超 200KB，远超 14KB 的 HTTP/2 单包理想阈值，反而拖慢 FCP。真正有效的做法是：让 Tailwind 只生成首屏用到的类，再把这部分 CSS 内联；其余样式异步加载。
tailwind.config.js 的 content 字段必须全覆盖且精确
这是整个优化的起点。Tailwind 不会“猜”你用了哪些类，只扫描 content 列表里明确写出的路径。漏掉一个文件，对应类就彻底消失。
- 必须包含所有模板、组件、JSX/TSX、Vue、Django 模板等路径，例如：
["./src/**/*.{js,ts,jsx,tsx,vue}", "./public/**/*.html", "./templates/**/*.html"] - 通配符必须带引号，扩展名不能省；
**/*.html不等于**/*.htm - 动态拼接的类（如
class="text-${size}-sm"）不会被扫描到，必须进safelist - 若用 Vite + SSR，还要加上服务端渲染时实际生成的 HTML 路径，否则提取结果和真实首屏不一致
safelist 要按需写正则，别堆字符串
静态扫描无法覆盖运行时生成的类名，但盲目加 safelist: ["*"] 就等于放弃按需打包。得用最小必要正则兜住高频组合。
- 推荐写法：
safelist: [/^text-(sm|base|lg|xl)$/, /^bg-(red|blue|gray)-(50|100|500|900)$/, /^p-[0-9]+$/] - 避免
/^.*$/或["text-red-500", "text-blue-500", ...]这类低效写法——前者失效，后者难维护 - 如果大量使用
@apply封装，safelist可大幅缩减，因为类名逻辑已下沉到 CSS 层 - 注意：Safelist 中的类仍要出现在 HTML 字符串里（哪怕只是注释），否则 JIT 编译器可能跳过
构建后必须验证关键 CSS 是否真被裁剪且覆盖首屏
配置写对 ≠ 生效。很多项目跑完 npm run build 就以为万事大吉，结果首屏仍白屏或错位。
立即学习“前端免费学习笔记（深入）”；
- 打开构建产物中的 CSS 文件（如
dist/assets/index.abc123.css），搜索.container、.hero等首屏类名，确认存在且无冗余 - 在 Chrome DevTools → Coverage 标签页刷新页面，检查 Tailwind 输出的 CSS 文件绿色占比是否 ≥95%；低于 80% 说明有漏扫或 safelist 不足
- 禁用缓存后看 Network 面板：HTML 响应体里
<style>块体积应 ≤14KB（gzip 前），且下方不应出现 render-blocking 的tailwind.css - 特别留意伪类（
.btn:hover）、响应式断点（md:text-lg）、暗色模式（dark:bg-gray-800）是否被提取——它们常因媒体查询嵌套被工具忽略
最容易被忽略的是：Tailwind 提取的关键 CSS 本身不带媒体查询上下文，而首屏在不同设备上匹配的规则完全不同。你得确保构建流程能识别 @media (min-width: 768px) 块里的规则，并在内联时保留完整块结构，否则移动端首屏可能直接崩 layout。
