1.实现目标： [图片] 在cover-view组件内实现如上效果 2.设计： [图片] [图片] 使得上层的字体可以覆盖下层的字体（使用z-index配置层级），达到目标效果 （ps.上图只是设想效果，实际上是可以完全覆盖住的） 3.代码实现： wxml： [代码]<[代码][代码]live-player[代码] [代码]style[代码][代码]=[代码][代码]'position:absolute;width:100%;height:800rpx;'[代码][代码]>[代码][代码]  [代码][代码]<[代码][代码]cover-view[代码] [代码]style[代码][代码]=[代码][代码]"position:absolute;bottom:40rpx;left:60rpx;background:#000;width:90%;height:200rpx;"[代码][代码]>[代码][代码]    [代码][代码]<[代码][代码]cover-view[代码] [代码]class[代码][代码]=[代码][代码]'name_and_content'[代码][代码]>{{name}}：{{content}}</[代码][代码]cover-view[代码][代码]>[代码][代码]    [代码][代码]<[代码][代码]cover-view[代码] [代码]class[代码][代码]=[代码][代码]'name'[代码][代码]>{{name}}：</[代码][代码]cover-view[代码][代码]>[代码][代码]  [代码][代码]</[代码][代码]cover-view[代码][代码]>[代码][代码]</[代码][代码]live-player[代码][代码]>[代码]js： [代码]Page({[代码][代码]  [代码][代码]data: {[代码][代码]    [代码][代码]name: [代码][代码]"河马Shawn"[代码][代码],[代码][代码]    [代码][代码]content: [代码][代码]"富强民主文明和谐自由平等公正法治爱国敬业诚信友善。"[代码][代码]  [代码][代码]},[代码][代码]})[代码]wxss： [代码].name{[代码][代码]  [代码][代码]position[代码][代码]: [代码][代码]absolute[代码][代码];[代码][代码]  [代码][代码]display[代码][代码]: [代码][代码]inline[代码][代码];[代码][代码]  [代码][代码]color[代码][代码]: yellow;[代码][代码]  [代码][代码]z-index[代码][代码]: [代码][代码]1[代码][代码];[代码][代码]}[代码][代码].name_and_content{[代码][代码]  [代码][代码]color[代码][代码]: [代码][代码]white[代码][代码];[代码][代码]  [代码][代码]white-space[代码][代码]: [代码][代码]normal[代码][代码];[代码][代码]  [代码][代码]position[代码][代码]: [代码][代码]absolute[代码][代码];[代码][代码]  [代码][代码]left[代码][代码]: [代码][代码]0[代码][代码];[代码][代码]  [代码][代码]top[代码] [代码]: [代码][代码]0[代码][代码];[代码][代码]  [代码][代码]width[代码][代码]: [代码][代码]100%[代码][代码];[代码][代码]  [代码][代码]height[代码][代码]: [代码][代码]100%[代码][代码];[代码][代码]  [代码][代码]z-index[代码][代码]: [代码][代码]0[代码][代码];[代码][代码]}[代码]4.实现效果图： [图片] 以上就是利用cover-view组件重叠的方式实现目标效果。

恩，这次小程序跳转的改动 第一，不需要同一主体的关联，这个很好 第二， 限制数量。这个我无所谓，当然，一堆瞎搞的，包括做小程序推荐平台的估计郁闷了。 第三。 跳转前有弹窗提示，这个就很坑爹了，本来互跳，对于一个正常的企业，做小程序矩阵是很常见的思路。本着小程序轻快的特性和包大小限制，现有业务拆分成几个小程序很正常的现象。本来用户基本可以0感知的情况下在企业的几个小程序之间互跳，完成不同的业务场景，现在“duang”给个弹窗提示是否要打开另一个小程序，这个从用户体验上大打折扣啊。 恩，今天打开发现弹窗似乎已经实装了。而且似乎，流量主广告上的小程序点击也会有弹窗。 恩，可以预想的是，今天流量主收入一定会大幅缩水。 恩，难道微信自己搬石头砸自己脚么。。。流量分成不也少很多了么？

我公司的小程序“小拼课“，已经上线几个月了。产品主要形式是免费为商家提供发布线下课程拼团的平台。 关于ios虚拟支付的问题，产品在立项前也进行了大量的前期调研。特别注意到官方对于虚拟支付的定义： [图片] 同时也参考了社区的同类帖子，关于线上付款，线下提供服务、提供课程培训是否被界定为虚拟支付： https://developers.weixin.qq.com/community/develop/doc/000eec47d58ba0f67d474e1c353400?highLine=%25E8%2599%259A%25E6%258B%259F%25E6%2594%25AF%25E4%25BB%2598%2520%25E7%25BA%25BF%25E4%25B8%258B https://developers.weixin.qq.com/community/develop/doc/00040a754c81087dddb77902a51800?highLine=%25E8%2599%259A%25E6%258B%259F%25E6%2594%25AF%25E4%25BB%2598%2520%25E7%25BA%25BF%25E4%25B8%258B 官方也在上述的帖子中明确提出了，线上付款，线下提供实际服务并非虚拟支付。 昨日突然收到微信通知，有用户举报小程序中有虚拟支付行为，结果今天，ios上的支付就彻底不能用了。 这里就很疑惑了？我们的产品肯定不算虚拟支付，为什么会有告警甚至屏蔽支付？ 难道这里又有所谓的双重标准？（你们去搜一下现在线上的各种搞教育的小程序，里面各种虚拟支付多的去了）怎么我们这个严格执行标准的反而被告警？ 请官方再次确认！！ appid： wx6ac1cba5bd71a219

希望能够像摩拜单车一样，能够获取到微信用户的微信上的实名认证信息 [图片]

- 当前 Bug 的表现（可附上截图） button 的submit事件失效 - 预期表现 点击button应该正常触发submit事件 - 复现路径 两个连续的textarea，先输入下方的textarea，然后输入上方的textarea，ANDROID手机submit事件100%失效 [图片] [图片] - 提供一个最简复现 Demo <form bindsubmit="formSubmit"> <textarea name='sell_address' class="weui-textarea" placeholder="请输入售楼地址"  /> <textarea name='intro'  class="weui-textarea" placeholder="请输入楼盘地址"  /> <button formType="submit" >保存房源</button> </form> Page({ data: {      }, formSubmit: function (e) { //按照复现路径，无法触发 console.log('form发生了submit事件，携带数据为：', e.detail.value) }, })

我想[图片]做一个横向滚动的滑轮，判定黑色的框里该展示哪一个视图，然后使用类似swiper的动画滑动过去，现在的问题是，scroll-view 没有结束钩子，不知道该什么时候判断。