如何实施Unocss后台的SVG图标方案？

在构建现代化的后台管理系统时我们往往会陷入一个看似不起眼却极其消耗精力的泥潭——图标管理。老实说这事儿真的挺让人头疼的。你有没有经历过这样的时刻：设计稿发下来几十个图标需要手动导入， 反正吧… 或者为了适配暗黑模式，不得不去修改那一堆堆看不懂的 SVG 路径代码？更别提那些老旧的插件，早已停止维护，依赖包报错的时候简直让人想砸键盘。

回想一下我们以前是怎么处理图标的？最原始的办法，直接把 SVG 文件当组件用。这确实可控，但一旦图标数量上百，import 语句能写满一屏幕，打包体积也跟着膨胀。 我血槽空了。 后来大家流行用 IconFont， 也就是阿里图标库，虽然方便，但字体文件加载慢、网络波动时图标变方块、多娱乐标支持差等问题，真的很难忍受。

出岔子。 从一开始的图标混乱， 到后来实现了 vite-plugin-svg-icons 停止维护的后顾之忧， 更通过 JIT 模式和 Safelist 的结合，完美平衡了性能与灵活性。

UnoCSS：不只是原子化 CSS 引擎

UnoCSS 不只是个原子化 CSS 引擎，它的图标预设方案简直是为解决这些痛点而生的。问题在于，menu.icon 的值是运行时才确定的！构建的时候，UnoCSS 扫描器根本不知道后端会传回来什么字符串。它只看到了一个模板字符串 `i-svg:${menu.icon}`，却无法解析出具体的类名，说起来...。

这就用到了 Safelist 机制。我们需要在构建配置里显式地声明哪些类名是需要被生成的，哪怕代码里没直接写死。这就用到了预处理的大招了。我们可以写一段 Node.js 脚本， 在构建前先去扫描图标文件夹，把所有的文件名都捞出来拼成类名列表，扔给 UnoCSS 的 safelist 选项，你看啊...。

动态场景下的关键问题：UnoCSS 的按需生成机制

行吧... 好了静态的图标我们会用了。