加了safelist仍丢样式，是因为purgecss仅匹配content扫描到的静态字面量类名，未显式写出的带前缀类（如md:text-red-500）或动态拼接结果（如text-${color}-500）根本未进入匹配队列，safelist无法兜底；必须确保content路径全覆盖，并用精准正则（如/^(?:md|hover):text-(red|blue)-\d+$/）或预定义字符串显式声明。
加了 safelist 还是丢样式？不是配置没生效，而是你列的模式根本没匹配到构建期提取出的类名——Tailwind 的 PurgeCSS 只在 content 扫描到的静态字符串上做白名单匹配，运行时拼出来的类名它压根不“看见”。
为什么 /^text-red-500$/ 保不住 md:text-red-500
因为 PurgeCSS 匹配的是源码中**字面量出现的完整字符串**，不是运行时渲染结果。你写了 md:text-red-500，它只认这个字符串；如果源码里只有 text-red-500，带前缀的就不会被扫描到，必须显式保留在 safelist 里。
- 错误写法：
/^text-red-500$/—— 完全不匹配md:text-red-500或hover:text-red-500 - 正确写法：
/^(?:md|lg|hover):text-red-(?:500|600)$/—— 把变体前缀也纳入正则 - 括号必须用非捕获组
(?:)，否则正则语法错误会导致整个 pattern 失效 - 如果项目只用
sm/md和red/green，就别写.*，收敛范围更安全
动态拼接类名（如 text-${color}-500）怎么加进 safelist
className={`text-${color}-500`} 这种写法，PurgeCSS 根本看不到 text-red-500 这个字符串——它只看到模板字面量 text-${color}-500，所以必须靠 safelist 主动兜底。
- 用函数式 pattern 更可控：
{ pattern: /text-(red|blue|green)-d+/ } - 避免
/text-.*/这种宽泛写法——它会意外保留text-clip、text-overflow等原生 CSS 属性 - 如果
color来自 JSON 配置或 CMS 字段（如item.classNames = "text-red-500"），这些字符串不会被静态扫描到，也得加进safelist - 优先考虑重构：把动态逻辑收口到组件内部，用
@apply封装成静态类，比依赖白名单更可靠
safelist 写太宽导致 CSS 体积暴增怎么办
safelist 不是“越宽越好”，写错一个点，可能让几百个未用类逃过清理。
-
/^w-/会保留全部w-*工具类（w-1/2、w-screen、w-max…），体积反弹明显 - 更合理的写法是按实际取值收敛：
/^w-(1/2|full|fit|auto)$/或/^w-[1-9]$/ - 启用
debug: true后构建，看控制台输出的preserved类统计——如果某条 pattern 贡献了上千个类，大概率写得太宽了 - 字符串形式的白名单（如
'bg-opacity-50'）只保单个类，适合零星关键类；正则适合批量模式，但必须验证边界
content 没配对时 safelist 也救不了你
safelist 只兜底“动态类名”，但前提是 content 覆盖了所有含 class 字面量的文件路径。漏掉路径，连 safelist 都没机会生效。
- React/TSX 项目必须显式包含
"./src/**/*.{js,jsx,ts,tsx}"，漏掉.tsx就等于把整个组件目录排除在外 - Next.js 要同时加
"./app/**/*.{js,jsx,ts,tsx}"和"./src/**/*.{js,jsx,ts,tsx}"（取决于你放组件的位置） - 如果用了自定义组件库或
.vue文件，路径也得一并加进去，否则里面写的text-red-500就算列在safelist里也没用
最容易被忽略的一点：safelist 的 pattern 不是“只要写了就保”，它只作用于 content 实际扫描到的那批类名。如果某个动态类名（比如 bg-dynamic-123）压根没出现在任何被扫描的源码文件里，pattern 再准也没用——它根本没进入 PurgeCSS 的匹配队列。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
