要重新打包，不用重新编译，用构建模板应该也可以
我询问的是那位老哥，他公司的引擎魔改了什么你也不确定吧。
理论上说魔改一般都是要重新构建引擎，而不是在运行时去魔改。
哈哈哈，很老的2d-js引擎，新项目肯定还是用3.x的
我也怀疑是的，复制失败文件等异常情况下，一些文件在缓存目录，但是没有被记录。我们是准备清理全部缓存，让玩家重进游戏了。
哈哈哈你都这么说了那必须信你，所以他改了什么？
我个人理解只有在运行时去修改（例如扩展 prototype）才不会影响微信的引擎插件才是
没那么简单。
首先你要改最底层的fsUtil，它那个deleteFile是异步的（你看传了一个callback），要对每个平台上的fsUtil，增加一个deleteFileSync，小游戏那些都有api的调用就是。
然后你封一个函数（例如叫deleteCacheFileListSync），给定文件列表，同步删除文件（一个循环调用），并同时去掉cacheFiles里面的条目，并同步的写入cacheList那个json。
然后你删除的时候，就LRU取一些文件，调用deleteCacheFileListSync就可以了。
大致是这个思路，不过我自己写的更简单，没有deleteCacheFileListSync的中间函数，LRU和同步删除在一起用的，抽出中间函数是解释的更加清楚一点。
最后删除的代码里面没有任何setTimeout，任何callback，和任何deffered闭包。
其实非常划算，我们就没考虑过用微信内置的cocos引擎插件，因为cocos的坑实在是太多了，除非非常小的项目，不然避免不了修改引擎的。
感谢回复，我本来也在纠结这块，你这么说的话我就果断改引擎了（坑确实多……）
看完了回复下，我要删评论
看到咯，感谢回复，学习了
删得好，删得好
你这个是 unzip/解压后的文件空间管理，在用户目录区
他说的那个是 .zip 文件本身，在临时区
会到你这个问题，大概率是因为我刚刚分析的那个回复里面导致的
clearLRU 由于可能会没有正确删除一些文件，并且此后没法追踪这些文件，导致这些文件一直堆积在用户区，没有人去管理删除，所以实际上你的用户目录可用空间上限会不断被减少，因为这些幽灵文件一直存在。
确实如此，因为这种玩家很少，所以直接清理整个缓存区重进了
这里有种情况 你们是怎么处理的？比如某个图片 被修改了，要更新吧，MD5变了，下次更新 新的文件进入缓存这没什么问题，但那么之前遗留的缓存 你怎么删除？好像要一直沉积在缓存区了吧 只能等LRU?
lru 就可以。
另外我们自己做了一套更加积极的删除机制，别说新版本的资源了，当前版本的资源，也很快删掉留不下来，重新下载总比爆缓存的好。
增加缓存时候 也是同步吗？我试了试 感觉不行，有效率问题，虽然稳定性有保证 但新资源同时多的时候 明显卡了就
你指的是增加的时候，写入cachelist 那个文件吗？ 那个可以同步的。
我改肯定不只是改那么一个地方，我有限制缓存文件总数量的（超过数量的删除），你限制在1000以内试试看。
是这样，有新的资源下载后 要进入缓存， 你得先写进cacheList.json吧 然后同步保存cacheList，然后同步拷贝文件进缓存区吧，
如果这个过程很频繁发生 等于是循环一直在下载 先到临时区，然后同步保存cacheList 再同步拷贝文件，数量密集的话 都是同步，你认为不会卡顿？
而且COCOS都是琐碎的文件还，挺烦人，解决了稳定性问题，还要面对效率
增加资源，只有这一步才是重要的吧，写进cacheList.json同步即可，其他下载和拷贝本来就是异步的，完成时候写入就可以。
同步主要是针对删除部分的，主要解决的是清理缓存的那个500ms删除一个的定时器拉长的异步过程，顺带改的增加写入条目同步。
另外卡顿不卡顿，不是我们思考来认为的，是要上实机测试的，我们那边限制缓存数量，1000-2000条文件条目，基本不会掉帧，超过2000了就会卡了，主要是写json卡。
比如增加了一个a.png的资源 先同步保存cacheList.json吧，然后呢 你的意思是 过一会a.png再从临时区拷贝到用户区？
那不等于和之前的删除同样的问题了 保存和拷贝不一致，导致cacheList和真实资源不对应的情况了？