做微信 / 抖音小游戏的同学，应该都被“主包超 4M”卡过：构建完一看超了，却说不清到底是谁占的空间、哪些能删、删了到底能不能变小。
我在做一个离线的包体分析插件（包体医生），新版本加了“主包 TOP20”和“安全删除分级”。这两个功能需要真实项目来验证，所以想免费帮 10 个 Cocos Creator 3.x 小游戏项目跑一份包体报告。
你会拿到什么
- 主包贡献 TOP20：主包里最大的 20 个文件，每个占主包百分之几、前 N 个累计占多少，并尽量追溯到工程里的源资源，附处理建议（移到子包 / 远程包 / 压缩）
-
安全删除分级：
-
未发现引用：不在任何场景 / 预制体 / Bundle 的引用链上，代码里也没出现它的 uuid 或文件名 -
可能动态引用：代码字符串里出现了它的名字，或者它在 resources / Bundle 里却找不到加载路径，需要人工确认 -
在用：不列出 - 每一项都会标注“删掉能不能减包体”
-
- 图片可省多少：没有透明通道的大 PNG、超大图、重复文件、没配压缩纹理的图；挑几张你最想压的，我实测给出“原来多少 KB → 处理后多少 KB”
- 最后附一句人工结论：先动哪几项收益最大
示例：官方公开教程工程 cocos-tutorial-airplane
用 Cocos 官方 MIT 教程工程 cocos-tutorial-airplane 跑了一遍，下面都是真实数据：
1. 一张背景图 1162KB → 107KB
assets/res/texture/bg01.png，720×1600，没有透明通道，1162KB。
- 转 JPG（质量 85）：107KB（-91%）
- 只做无损 PNG 重压：1118KB（只省 4%）
体积是我用 Pillow 实测的，画质需要自己看一眼。背景图一般看不出差别，UI 小图和渐变要谨慎。
2. bg01.png 和 bg02.png 是同一张图
两个文件 MD5 完全相同，各 1.14MB。场景只用了 bg01；脚本里虽然有 bg02，但那只是个变量名（bg02: Node = null;），并不是在加载 bg02.png。所以 bg02.png 被判为 未发现引用。只有字符串里出现文件名（比如 resources.load('xx/bg02')）才会被算作 。
3. 一个教训：删了 1.92MB 未引用资源，包体减少 0
这个工程里扫出 4 个未引用资源，共 1.92MB（包括上面的 bg02.png）。但不在引用链上的资源本来就不会进入构建，全删掉只是让仓库变干净，包体不会变小。真正“没用却进包”的，是 resources 和 Bundle 目录里没人加载的东西。所以报告里每一项都会标“减包体：是 / 否”，免得白忙一场。
另外，这个工程在用的 8 张大图，按“无透明转 JPG、有透明转 PNG8”逐张处理，实测合计 4094KB → 738KB。注意 JPG 重存属于二次压缩，需要实机确认画质。
说明：教程工程本来就不追求包体，只是拿来演示。它没有 Bundle，也没有构建目录，所以上面没有 TOP20 的数据。TOP20 功能是新加的，还没在真实项目上验证过，这正是这次招募的原因。
工具是怎么工作的
- 离线、只读：不联网、不上传，不修改、不删除工程里的任何文件。报告里的“可删”只是建议，删之前请先提交 Git
-
不用给我工程：你在本地跑完，只把生成的
report.json发给我 -
report.json里有什么：资源的相对路径、文件名、体积、尺寸、引用统计；没有源码，默认也不含你电脑上的绝对路径。如果文件名本身也不方便公开，可以只私信给我，我不会公开引用
怎么报名
- 在本帖下回复：引擎版本 + 目标平台（例如“3.8.6 + 微信小游戏”），如果愿意，可以加一句现在主包多大、想压到多少
- 我会通过论坛私信发你测试版插件和使用说明（编辑器菜单：扩展 → 包体医生 → 体检工程 + 微信小游戏构建）
- 你把
report.json私信发回给我，我整理好报告再私信给你
条件：Creator 3.x 项目，小游戏平台优先；先到先得，满 10 个会在帖子里更新“已满”。
交换（可选）
报告免费。如果你愿意，希望你按建议优化后告诉我“优化前 / 后”的主包数字，我可能会匿名引用（不带项目名和文件名）；不愿意也完全没关系。
已知限制
- 通过拼接字符串、配置表或服务端下发路径加载的资源，静态分析无法 100% 识别，所以才有 这一级，需要人工确认
- 不分析脚本代码本身是否被使用；不支持 Creator 2.x
- 图片压缩的效果因图而异，报告里只给实测数字，不做“一定能压到 4M 以下”这种承诺
有误报或漏报的案例也欢迎直接在帖子里说（可以脱敏），我会优先修。