【问题背景】 近期在优化一款小游戏项目的包体体积。项目采用了多 Bundle 分包策略，并大量使用引擎自带的 AutoAtlas （自动图集）进行 DrawCall 优化。但在最终构建产物中，发现分包体积远超预期。
【排查过程】 最初怀疑是常规的“跨 Bundle 交叉引用”导致的资源重复打包。但在理清所有依赖链（确保无交叉引用）后，通过比对构建后的资源 UUID 发现， 问题出在 AutoAtlas 的打包策略上。
【核心结论：Double Retention 机制】 我发现了一个会导致包体直接翻倍的现象： 只要原始碎图被 Prefab 静态引用，合图就会失效并产生双重冗余。
- 场景复现 ：
- 在某个资源目录下存放碎图，并配置 auto-atlas.pac 。
- 在 UI 预制体（Prefab）的 Sprite 组件上，通过编辑器直接拖入该目录下的碎图资源。
- 构建结果 ：
- 控制台触发警告： Warn: [Assets] 图集内的图片资源已被其他资源直接使用，被依赖的 texture 及其 image 资源将会被一同打包出来… 。
- 检查构建产物（构建后的资源目录）：同一个资源的 UUID，既被打进了一个大图集 PNG 中，又以原始碎图 PNG 的形式单独存在。
- 技术总结 ：
- 这不是依赖链断裂的问题，而是 Cocos 构建管线在处理 AutoAtlas 时，为了兼容静态引用，采用了最保守的“全量导出”策略。这种 Double Retention（双重留存） 导致一份资源占了两份空间。!
- 官方是否考虑在构建阶段，将这种静态引用自动重定向到合图后的 SpriteFrame 偏移量上，而不是简单地重复打包？
- 除了手动将资源移出合图目录或设置 Packable=false ，大家在大型项目中有没有更自动化的规避方案？
image|690x226
