虚拟支付 用requestMidasPayment的env用1 ，结果看到微信里的支付通知还是被扣费了， 请问这个沙箱方式的存在 是为了什么？这个被扣费的结果正常吗

比如第一个版本更新150M 资源是远程管理的 用户都下载了 那么缓存有150M了吧 然后随着版本的更新 有些资源不会再用了 有些新资源会被渐渐加进来，比如每个版本更新 包体大小都是150M， 那么十几个版本后，可能最后的版本的资源已经完全和第一个版本不同了 按照这种方式 那么用户的缓存可能有至少300M了 而且肯定还不止300M ，那么请问这种模式 更新运行，是否会有问题? 但能保证 每个版本 本身都是小于200M的 比如都不超过150M 那么资源缓存的管理 面对版本不断更新 新资源陆续加入的情况 是如何处理的？ 比如还有可能 某个资源从版本1到版本20一直都没变过，那么是否也会有影响？

[图片][图片] 11步这里 如果到账延时，此时查询余额比如为0，但如果此时调用cgi-bin/midas/pay 去扣除金额 那么结果会如何？ 会不会操作成功了 但过一会金额又到账了？等于实际没有扣除？用户还有余额？ 还是说 就算是延时到账 扣除操作提前进行 也能真正扣除成功？后期查询余额 还是0？ 这里会是个什么情况 请给个说明看

[图片][图片] 已经关联了商户号，在接入微信支付状态栏 显示已申请， 这个已申请 表示是正在审核中？ 还是说审核通过了？ 请给说明一下 谢谢

requestMidasPayment返回的消息中只有成功失败，那么服务端怎么对应是这次的操作呢？ 按照文档里的流程只是检查余额是否够 ，那么好像没有返回什么本次操作的交易码之类的 所以想问问 这个设计机制 就是这样吗 就是只以余额为准吗？ 这个设计初衷就是这样吗

[图片][图片]这个是个小游戏的例子，商店里有购买清单 点某个物品，直接调出了微信支付，那么请问这个是怎么实现的？ 是微信支付？还是虚拟支付？小游戏能支持微信支付吗？请给解释一下 谢谢！

快被你们的文档给搞晕了 后台管理里 有开通微信支付 和开通虚拟支付的管理 ，申请了微信支付 然后还有连接指引到微信支付的文档区，但怎么看怎么不对啊 小游戏里也没有调用微信支付的接口啊 目前只有虚拟支付，到底是个什么情况啊 你们的文档就不能说清楚一点吗 让用户去猜吗还

看说明是这样：为保护用户设备的可用空间，系统会对所有开通提升的游戏定期清理文件，以文件为维度按照最近使用时间从远到近进行清理。即开通后不保证文件永久存储，请开发者合理使用 问题是 系统怎么知道哪些文件有用 哪些没用呢？ 如果删除了 不就出问题了吗要？ 请问这个删除规则是什么？应用方 应该做什么工作对应这种规则？

首先想知道小游戏如何管理更新主包和分包的资源，每次更新是完整删除主包和分包吗 还是覆盖更新？ 比如旧的版本有一个主包 和多个分包， 包里各种资源 名称也不同，因为可能加了DM5验证 文件名字可能带有MD5标识都， 如果是完整删除所有旧包的方式 那就不存在多余文件的问题了 ，因为只有新包的文件了 当然这种最简单 如果是覆盖方式 就复杂了，那么更新版本后 主包和分包里 可能更新了几个文件就，那么每次更新 会有之前版本遗留的多余的文件出现了就 那么可能会有累计效应，主包和分包的目录 会越来越大，所以想知道小游戏 管理包更新是个什么 方式和规则？

FileSystemManager的stat方法 参数recursive为true，然后路径为wx.env.USER_DATA_PATH， 那么应该得到所有的wx.env.USER_DATA_PATH下所有子文件和子目录的列表了吧， 然后如果其中某个是目录而不是文件， 那么再递归调用FileSystemManager的stat 得到每层子目录下的列表 依次循环，应该就是所有的文件列表了吧？ 但目前测试看到的现象是 比如只检查wx.env.USER_DATA_PATH的子目录 比如得到的结果是 name1=/gamecaches name1=/gamecaches/main name1=/gamecaches/resources 感觉好像是直接返回了包括所有深层子目录的总和，也就是说好像已经是被递归过了都， 所以想问问，这个参数recursive为true时，是已经自动递归了参数路径下 包括深层子目录的所有文件了吗 也就是说用户不用再自己递归调用了都？