引擎中是这样处理的 比如某个远程文件 http://ip/remote/resources/native/96/960dd8a0-61b7-4cf1-83c0-576aa4340cea.fe7f9.png ,被缓存后 会被随机替换成一个文件名，比如 localPath最后可能是177932735958721.png，但我认为没必要用这种方式吧
完全可以直接用 960dd8a0-61b7-4cf1-83c0-576aa4340cea.fe7f9.png 的，然后放到对应的bundle目录下，也就是说 没必要再管理 localPath这个数据了就，每次根据原地址就直接知道本地文件名了 多方便的？少了一层管理的还？ 有谁觉得是问题的吗
比如说个 可能有问题的环境情况？
您误会了，这本来就是纯讨论帖，就是说问题的， 哪怕是个例的非主流的环境 真的存在就说说看的也，因为我目前看到的主流的机型和环境 没有这个情况还
不排除有设备会因为文件名过长、命名存在多个点导致崩溃。而且这样处理也没什么问题吧？
看代码了，这个__cacheBundleRoot__需要自己传参数才能生效。你用http://ip/remote/resources/native/96/960dd8a0-61b7-4cf1-83c0-576aa4340cea.fe7f9.png，下载器怎么知道resources是不是分包？这是适配平台的胶水文件，不是业务代码，严禁写高度兼容代码。要考虑通用性和兼容性。而且原先设计是按下载时的时间戳加自增id命名的，这样本身没什么问题。是比较规范的缓存机制。如果要实现你那样的规范，下载怎么知道当前下载的文件是哪个分包的？那如果不是分包里面的文件又要怎么搞？
你看错了吧 cacheBundleRoot是系统告诉你的 不是你控制的，这个就是属于哪个Bundle的了，没有Bundle的 就放到默认目录下，
而且关键是本来就是以原地址中的960dd8a0-61b7-4cf1-83c0-576aa4340cea.fe7f9.png 这段信息为索引，COCOS管理文件也是以这个为准的，这个不会重复，重复了那也COCOS本身的事，那么 960dd8a0-61b7-4cf1-83c0-576aa4340cea.fe7f9.png 这个索引 直接当成本地文件名 加上Bundle名，我从理论上 没看出问题还，
但如果说 960dd8a0-61b7-4cf1-83c0-576aa4340cea.fe7f9.png 这个如果哪个系统不支持比如? 那的确是个换名称的理由
确实 看漏了，是transformPipeline自动获取分包名的。那你像你那样改吧，没问题