purgecss 的 safelist 正则需精准匹配动态类名变体，如 /^(?:md|lg|hover):text-red-(?:500|600)$/；动态拼接类名须用函数式 pattern 如 /text-(red|blue|green)-\d+/；content 路径必须完整覆盖源码文件，否则 safelist 失效。
为什么safelist里的正则总漏掉 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,ts,jsx,tsx}"和"./pages/**/*.{js,ts,jsx,tsx}",否则dark:、group-等上下文类极易丢失 - 静态 HTML（如
public/index.html）写了class="p-4",也得手动加进content,否则被当“死代码”清空 - 第三方 UI 库（如 DaisyUI）若在
node_modules里用了 Tailwind 类,需单独列路径："./node_modules/daisyui/dist/**/*.js"
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
