[图片] [图片] 使用miniprogram-ci上传时，会在图一位子卡死【20分钟左右】，之后会完成，接着出现报错如图二。 是近一星期才发生的情况，时好时坏。

小程序运行时，在ios上发热严重，如何定位排查问题？ 官方是否有一些指南和方案，来优化。

我将一个下载下来的zip包，使用saveFile将临时文件转换为本地文件。 之后我使用unzip对zip包进行解压。那解压后得到的文件是临时文件，还是本地文件

小程序寄生在微信中，所以享受到了极大的分享便利，也是微信小程序对于其他平台的一大优势。 但是分享流程的测试却不太好处理。希望和大家讨论一下这个问题，是否有好的解决思路。 现有分享的主要场景： 1.原生app分享小程序卡片 2.服务端生成小程序码 这两个场景都需要指定appId，场景1中可以指定任意版本小程序。 场景2只能指定生产版本。 小程序的appId与对应的ak是绑定的，在环境部署中，出于安全考虑，pro环境的ak不会部署在dev，qa环境下，而是选择另外申请了一套测试用小程序，dev，qa使用测试用appId（以下简称_test_appId)，并且未发布审核 那这样就造成了环境的问题。 场景1中，原生分享出的小程序卡片对应的小程序一定是正式小程序的appId，而实际的k8s中的微信相关服务（例如UC）使用的还是_test_appId 这导致相关功能无法正常测试。 场景2的情况会更严重一些，由于未发布，所以服务端是无法生成_test_appId小程序码的。 现有解决思路： 1.不解决，分段测试，测试初期保证相关功能的数据是正确的，之后待小程序相关功能上线之后，再测试所有功能的完整性 问题：会导致测试割裂，并且需要线上验证。 2.将_test_appId对应的小程序发布出去，设置为 隐藏搜索, 这样能解决完全解决场景1的问题，而场景2则是属于能生成小程序码，但实际功能无法确认的状态。 问题：需要额外发布一个测试用小程序，是否违规。隐藏搜索功能是否能到完全屏蔽普通用户的效果。 针对以上情况，大家的做法怎样的呢，官方是否有建议方案呢？ 希望讨论一下。

bindtransition中只返回了{dx,dy}信息，无返回相对应的SwiperItem。而swiper中的bindchange事件，会在滚动具体超过一定距离之后直接触发。所以也无法通过外部维护swiper的current达成效果。期望在bindtransition中能返回对应的swiperItem的itemId。

直播商品使用了原生的路由跳转，如果是指向tab页url无法携带参数

在分享场景（小程序码，or分享卡片）中，都会携带一个目标页。 是否能在生命周期中拦截掉跳转目标页的行为，而直接导向到其他页面。 例如在app.onShow中发现未登录，直接跳转到登陆页。 现在的设计好像无法阻止掉默认跳转的行为，导致大家在设计架构时，必须加入启动页或者首页。（例如小红书，定位到首页，再有首页转发，实际体验惨不忍睹） ————更新———— 希望能提供一个全局路由守卫钩子，无论是switchTab 还是relaunch等，涉及到此小程序路由变化时，能够进行拦截。（现在还有新的场景，例如直播时商品的跳转）