首先从社区来看，其实有很多开发者都有在后台/熄屏时连续播放背景音频的需求。（这里的连续指当一条音频资源播放结束后，继续播放下一条音频） 目前开发者基本上是通过监听onEnd方法，然后重新设置src以达到连续播放。 [图片] 但实际上，这个方法是存在设备兼容性问题的，在很多设备上无效。 通过仔细查阅官方文档，其实已经有说明： [图片] 所以，无法连续播放才是符合官方预期的。 那么官方为什么如此设定呢？然后我也在社区发现官方人员的说法： [图片] 我不知道后面官方讨论的结果是什么，但我认为，在一条背景音频资源播放结束后，后台继续播放下一条音频，不是突然播放声音这种情况，所以对用户体验不会存在负面作用。相反，那么多开发者都存在这一需求，也代表着用户的需求。 综上，希望官方能够优化背景音频api，提供后台连续播放能力。 谢谢🙏

目前综合排序直接草率地按照评论历史点赞量排序，会导致明显的马太效应，不能够准确的反映小程序近期的用户满意度。 例如 在用户使用过程中，好评用户通常会在退出小程序后，根据微信引导发布新的评价；而差评用户往往由于情绪原因，主动进入小程序评价页面（默认展示综合排序），对差评进行点赞。 如此就会出现一种不合理的情况：大多数用户好评，极少数用户差评，小程序评分很高，但综合排序头部都是差评。 这对于小程序运营非常不友好，希望能够改进！

当前channel-video默认只要在页面中渲染就会进行视频预加载，当页面中包含多个channel-video组件的情况下，会加载大量的视频资源，造成不必要的带宽浪费，也会影响程序性能。实际上小程序对内嵌视频号的预加载需求并不高，希望能够优化一下

滚动picker-view后，再播放innerAudio(开启WebAudio实现）时，会出现明显的杂音

https://developers.weixin.qq.com/miniprogram/dev/OpenApiDoc/sec-center/sec-check/mediaCheckAsync.htmlhttps://developers.weixin.qq.com/miniprogram/dev/OpenApiDoc/sec-center/sec-check/mediaCheckAsync.html

第三方平台api接口getApiQuota查询小程序名称检测checkNickName报错76022could not use this cgi_path, no permission rid: 62e90dc5-7f0b578a-5bba98e7 尝试了component_access_token和authorizer_access_token都报同样错误

已确认开启了gps定位并且授权，通过调试发现接口返回值provider为network，为何没有调用gps？

[图片] 如图，好多天了一直不显示数据？麻烦确认下问题谢谢！