确认真冗余图片需三步：先查产物目录中未被import/require/v-bind:src引用的static/下图片；再用findunusedassets.js脚本比对源码路径与文件实际存在性；最后人工验证manifest.json、subnvue、native逻辑等非常规引用，避免误删。
怎么确认哪些图片是真冗余
打包产物里看着多，不等于都是冗余。uni-app 构建后，unpackage/dist/build/mp-weixin 下的图片只来自三处：项目根目录 static/ 中被页面或组件直接引用的、components/ 或 pages/ 里 require() 或 url() 加载的、以及通过 background-image 写死路径的。没被任何地方 import / require / v-bind:src 引用的图片，才是可删的“幽灵文件”。
别信 HBuilderX 构建日志里那句“共拷贝 XX 个资源”——它不区分是否被引用。必须进产物目录，用系统排序按大小倒序看，重点盯 .png、.jpg、.webp 文件，再反向查源码里谁在用它。
- 用微信开发者工具右键分包目录 → “在资源管理器中打开”，按大小排序，一眼识别 >200KB 的图
- 用
grep -r "logo.png" src/（Linux/macOS）或 VS Code 全局搜索，确认是否还有残留引用 - 注意：
static/下以_或.开头的文件（如_temp.jpg）默认不会被打包，但若被显式require()过，就会进包——这类最易漏判
如何安全批量删除未引用图片
手动删容易误伤，尤其当项目用了 easycom 或动态组件时。推荐用脚本自动化检测，比靠眼睛扫准得多。
知识库中提到的 findUnusedAssets.js 工具能扫描 src/ 下所有 JS/Vue/CSS 文件，提取所有字符串形式的图片路径（包括 url("...")、:src="..."、background: url(...)），再比对 static/ 目录下的实际文件，输出真正没人要的列表。运行后它还会按文件夹统计可释放空间，比如告诉你删掉 static/tmp/ 下 12 张图能省 1.8MB。
- 执行前先
git add .提交当前状态，避免删错无法回退 - 该工具默认不处理
static/icons/下的字体图标文件（.woff、.ttf），如需检查，得手动加扩展名配置 - 如果项目用了
uni.downloadFile动态拼 URL（如https://a.com/${id}.png），脚本无法识别——这类图不属于“打包冗余”，而是运行时加载，不用删，但要注意服务端缓存策略
删完还要防它再长出来
删一次不等于一劳永逸。开发过程中设计师扔新图、测试时截图存 static/test/、临时注释代码里留着 require("@/static/old-banner.jpg") ——这些都会让冗余资源悄悄回归。
- 把
findUnusedAssets.js加进package.json的"scripts"，例如："clean:assets": "node ./scripts/findUnusedAssets.js ./src"，每次发版前跑一遍 - HBuilderX 的“代码检测”功能对图片无感知，但可以开启 ESLint 规则
no-unused-vars配合自定义插件，拦截const logo = require("@/static/logo.png")后又没使用的变量 - 团队协作时，在
static/下建__deprecated__/子目录，把待确认图片挪进去，而非直接删——给 review 留个缓冲期
特别注意：这些图删了会直接报错
有些图片看似没被引用，实则通过非常规方式加载，删了会导致白屏或 404。
-
manifest.json里的icon、splashscreen路径指向的图片，即使没在 JS 里出现，也绝对不能删 - 使用了
uni.loadSubNVue加载的原生子窗体，其style中写的background图片路径，不会出现在 Vue 源码里，得单独检查subNVue/目录 - 通过
plus.io读取的私有目录图片（如plus.io.getCacheDir() + "/avatar.jpg"），它们根本不在static/下，也不在打包产物里，跟本次清理无关——但容易和冗余图混淆
真正难清理的从来不是“多出来的图”，而是那些“看起来多余、其实被某行不起眼的 native 逻辑或条件编译挡板悄悄挂着”的图。每次删之前，务必真机跑一遍核心路径，尤其是 tab 切换、下拉刷新、分包跳转这些容易触发隐藏资源加载的场景。
