虽然我的项目也是颗粒化分包，但是我删除的形式没有按分包来，还是按文件LRU，只不过是持续控制阈值（看我2L的方案回复），就是边下边删，不会等超过缓存的时候再删。
怎么能知道当前缓存已经有多大了是？用什么方法算的 比如微信小游戏平台
1.控制cache内的资源，通过2个阈值：条目数量，总大小。
条目数量：较少的条目数量，会让cachelist 写入不会卡顿。我控制在1200条。
总大小：控制大小不超过平台对应的限制，另外加上余量。我控制在150M。
每加入一个文件，我都会检查，如果超过阈值，立即删除64个cache内的文件。
为了支持大小统计，我对每个条目加入了size项。
整体上，cachelist也加入了total size 的统计项。
原本引擎是没有的。
下的什么就存的什么地址，你们下载是直接请求具体资源的url？没直接下载整个分包？还是分包里面还有更严格的资源划分？
没有用zip压缩？
部分分包，例如配置表，和一些压缩比比较大的用zip。
其他用散文件。散文件就是用到什么文件下什么文件，散文件也属于分包内的文件，只是用cocos本身分包的机制（信息文件+散文件），用到的时候下载而已。
某些核心玩法的分包，可能在逻辑里面会预下载，那种一下就一整个分包（内的所有散文件）。
就是说我们项目里面，有zip，也有散文件，有提前预加载一个分包下，也有散着用什么下什么。看具体资源情况而定。
对，永远僵在那里，除非清理整个缓存目录。
有是有办法解决，不过需要一点开销，就是cocos在访问cache的时候，要判断实际文件是否存在，再返回是否成功。
我处理抖音的temp file被删除就是用的这个机制。但cache懒的改了，而且效率并不高，它调用的statusSync（可能叫这个）判断文件是否存在，同步调用会有点卡。
可以记下版本号，更新版本的时候，读cacheList 然后删掉老的zip包试试 2.4.x这么干过 。