遇到一个问题，因为开放平台的绑定数量限制。但是我们又需要对N个不同的公众号实现用户打通。 那么我可以通过，把这些不同公众号授权给同一第三方平台后，实现用户打通吗？ PS: 不同公众号授权给同一第三方平台后，不同公众号内的用户的unionID是不一样的吗？

境外小程序与国内小程序有哪些不同，先列几条： (2022.6.9更新) 1、小程序注册 境外只能注册服务号(99刀)，可通过服务号快速注册小程序； 2、支付 境外支付除香港“统一钱包”，其他地区都只能找第三方接入； 可接入其他支付方式比如paypal, sofort等，甚至某宝； 具体看这篇，即可： https://developers.weixin.qq.com/community/develop/article/doc/00042029678c88c81bfdfff9f51413 3、社交功能 基本不支持社交功能； 企业微信群插件：不支持； 4、直播、视频号、交易组件 基本都不支持； 直播可能可以通过第三方平台开通(尚未验证)； 5、视频 Video标签无需资质即可使用，审核可直接通过。 腾讯视频插件：不可用； 6、云开发 2022年开始，全面禁用。 之前注册的小程序，仍支持。 7、电话号码 无权限获取； 8、开放平台 无差别； 9、第三方平台型服务商 无差别； 第三方快速注册小程序：不支持； 其他凡是自动识别主体信息的接口，都不支持。 10、小程序消息机制 订阅消息，无差别； 统一服务消息：支持，但海外用户可能收不到公众号模板消息。(仅经验，无法验证) 11、小程序服务类目 很大区别，需要认真研究对待； 所需资质不同，以营业执照为主； 12、语言 小程序基本都得提供双语，甚至多语言功能； 13、电商方面 商品税费、物流、跨境等，基本与国内都不同；需要区别对待。 14、短信验证码 国际短信 15、位置服务 2022年开始，前端位置服务全面禁用。 后端位置服务：建议使用腾讯位置服务海外版，Here位置服务； 16、邮件 很常用，基本一定会用到； 17、小程序客服 基本无法满足境外需求； 完全无法实现多语言化； 已尝试多次，如有人成功了或者有其他方案，请一定留言告知。

api 顾名思义 wx.openMiniProgramHistoryList wx.openMiniProgramProfile wx.openMiniProgramSearch wx.openMiniProgramStarList 不再多BB直接上图 1.隐藏/显示右上角胶囊按钮 [图片] 2.截屏 [图片] 最近玩console有点上头 现在的小程序api已经达到了373个了 我是怎么知道的？看图 [图片] 往下拉一看 373 [图片] 这里边有很多的api 是文档中没写的（也可能永远不会写） 先说下 普通的小程序里边是没有权限的调用会提示 {errMsg: “openUserProfile:fail:access denied”} 或者 {errMsg: “getABTestConfig:fail permission denied”, errCode: 1} 代码片段：https://developers.weixin.qq.com/s/FgIssdmP7jdv 可用的api wx.navigateBackH5 --webview 通过这个api可以返回上一个web页面 更多的BUG等你们去处理 我吃饭去咯 end

公告更新时间：2021年04月15日考虑到近期开发者对小程序登录、用户信息相关接口调整的相关反馈，为优化开发者调整接口的体验，回收wx.getUserInfo接口可获取用户授权的个人信息能力的截止时间由2021年4月13日调整至2021年4月28日24时。为优化用户的使用体验，平台将进行以下调整： 2021年2月23日起，若小程序已在微信开放平台进行绑定，则通过wx.login接口获取的登录凭证可直接换取unionID2021年4月28日24时后发布的小程序新版本，无法通过wx.getUserInfo与<button open-type="getUserInfo"/>获取用户个人信息（头像、昵称、性别与地区），将直接获取匿名数据（包括userInfo与encryptedData中的用户个人信息），获取加密后的openID与unionID数据的能力不做调整。此前发布的小程序版本不受影响，但如果要进行版本更新则需要进行适配。新增getUserProfile接口（基础库2.10.4版本开始支持），可获取用户头像、昵称、性别及地区信息，开发者每次通过该接口获取用户个人信息均需用户确认。具体接口文档：《getUserProfile接口文档》由于getUserProfile接口从2.10.4版本基础库开始支持（覆盖微信7.0.9以上版本），考虑到开发者在低版本中有获取用户头像昵称的诉求，对于未支持getUserProfile的情况下，开发者可继续使用getUserInfo能力。开发者可参考getUserProfile接口文档中的示例代码进行适配。请使用了wx.getUserInfo接口或<button open-type="getUserInfo"/>的开发者尽快适配。开发者工具1.05.2103022版本开始支持getUserProfile接口调试，开发者可下载该版本进行改造。 小游戏不受本次调整影响。 一、调整背景很多开发者在打开小程序时就通过组件方式唤起getUserInfo弹窗，如果用户点击拒绝，无法使用小程序，这种做法打断了用户正常使用小程序的流程，同时也不利于小程序获取新用户。 二、调整说明通过wx.login接口获取的登录凭证可直接换取unionID 若小程序已在微信开放平台进行绑定，原wx.login接口获取的登录凭证若需换取unionID需满足以下条件： 如果开发者帐号下存在同主体的公众号，并且该用户已经关注了该公众号如果开发者帐号下存在同主体的公众号或移动应用，并且该用户已经授权登录过该公众号或移动应用2月23日后，开发者调用wx.login获取的登录凭证可以直接换取unionID，无需满足以上条件。 回收wx.getUserInfo接口可获取用户个人信息能力 4月28日24时后发布的新版本小程序，开发者调用wx.getUserInfo或<button open-type="getUserInfo"/>将不再弹出弹窗，直接返回匿名的用户个人信息，获取加密后的openID、unionID数据的能力不做调整。 具体变化如下表： [图片] 即wx.getUserInfo接口的返回参数不变，但开发者获取的userInfo为匿名信息。  [图片] 此外，针对scope.userInfo将做如下调整： 若开发者调用wx.authorize接口请求scope.userInfo授权，用户侧不会触发授权弹框，直接返回授权成功若开发者调用wx.getSetting接口请求用户的授权状态，会直接读取到scope.userInfo为true新增getUserProfile接口 若开发者需要获取用户的个人信息（头像、昵称、性别与地区），可以通过wx.getUserProfile接口进行获取，该接口从基础库2.10.4版本开始支持，该接口只返回用户个人信息，不包含用户身份标识符。该接口中desc属性（声明获取用户个人信息后的用途）后续会展示在弹窗中，请开发者谨慎填写。开发者每次通过该接口获取用户个人信息均需用户确认，请开发者妥善保管用户快速填写的头像昵称，避免重复弹窗。 插件用户信息功能页 插件申请获取用户头像昵称与用户身份标识符仍保留功能页的形式，不作调整。用户在用户信息功能页中授权之后，插件就可以直接调用 wx.login 和 wx.getUserInfo 。 三、最佳实践调整后，开发者如需获取用户身份标识符只需要调用wx.login接口即可。 开发者若需要在界面中展示用户的头像昵称信息，可以通过<open-data>组件进行渲染，该组件无需用户确认，可以在界面中直接展示。 在部分场景（如社交类小程序）中，开发者需要在获取用户的头像昵称信息，可调用wx.getUserProfile接口，开发者每次通过该接口均需用户确认，请开发者妥善处理调用接口的时机，避免过度弹出弹窗骚扰用户。 微信团队 2021年4月15日

微信小程序AR [图片] 第一步、AR商品识别 扫一扫产品，扫一扫LOGO，扫一扫海报，扫一扫门店 基于AR图片识别技术，自己上传识别图，自定义识别操作 [图片] 第二步、交互式三维展示 360度产品展示、合拍分享到社交媒体 基于PBR物理渲染引擎，动画，支持手势缩放/拖拉/旋转操作 [图片] 第三步、虚拟试戴、虚拟化妆 逼真试戴体验、引流到在线商城 适合web/小程序的轻量深度神经网络、快速加载，对接微商城/微信小商店 「PLAY2XR眼镜试戴」 [图片] 「PLAY2XR口红试色」 [图片] 「PLAY2XR戒指试戴」 [图片] 扫码体验 [图片]

体验码（已上线，非具体需求用户请勿支付，如误操作，请联系客服商家动态微信退款） [图片] 下面看下演示 [图片] 开通步骤： 1、首先你得有个营业执照 2、打开微信-我-支付-收付款-二维码收款-收款小账本（或者直接搜索小程序：收款小账本） [图片] 3、补充经营信息，开启商家服务，需要上传营业执照 4、审核通过后，继续收款小账本首页，下单助手、商家动态等去完善店铺信息 5、信息完善后点击【收款小账本】头部店铺名称，然后再点击商家小程序即可打开小商店助手，然后进入我的小程序，就能打开啦 6、剩下的就是店铺活动，各种信息完善了 Tips：此小程序名称格式必须是是【主营业务|地理区域】，然后店铺名称可被全网搜索到

[图片]                                            大家好，我是小打卡的前端负责人金轩正，今天分享的主题是如何基于微信原生构建应用级小程序底层架构，这个命题看上去好像有些大，不过不要紧，这次分享我把它拆一下，大致从 小程序原生开发面临的问题 小打卡整体架构演进 开发中摸索与实践 这三个方面来看这个讲一下 [图片]                                            小程序原生开发面临的问题[图片]                                            ok，首先第一个方面原生开发遇到的问题 小程序从17年诞生2年来一直处于互联网风口，不过对于开发者而言的整个开发体验不是特别友好，在17-18年之间我和很多开发小程序的小伙伴们聊过，大多数的反馈可能分为下面大致几类，当然还有更多: 没有父类，无法使用继承挂载全局方法，扩展生命周期没有父类，无法使用继承挂载全局方法，扩展生命周期 不支持跨页面/多页面通讯 setData的性能瓶颈 代码包大小限制 1/2/4/8 M，没有npm包 代码发布流程繁琐 其根本原因是将刚刚诞生的小程序与已经非常成熟的React，vue，angular作对比，而没有将小程序作为一个新的生态来看待，当然这个是一种看待事物的进步，并不是倒退，我在这里说这句话的意思是有更多的问题需要我们开发者主动去解决问题，推动整个生态的前进与发展 [图片]                                            其实这里可能有些朋友会问，已经有很多优秀的框架已经解决了这些问题，那么为什么还要使用原生开发？ 确实在这段时间内出现了很多优秀的解决方案，我们不用并不是因为情怀哈（当然还是有那么一丢丢） 更多的是下面几点： 历史包袱，改造成本过高  小打卡在小程序刚出现的时候就进入开发了，当时框架还不成熟，而且对创业公司来说时间和迭代效率高于一切，在人手不足，业务模式尚未形成，还处于探索阶段的情况下花费大量时间去做对产品影响较小, 甚至delay迭代速度事情不是很赚 减少与第三方沟通成本 高速迭代的情况下，将时间尽可能的覆盖于业务上，避免在整个开发-上线闭环上增加节点 避免开发黑盒，控制风险 虽然整个社区是非常活跃的，fixed一个问题同样是需要花费一定时间，但是很多时候需求是不会等你bug fixed 如非必要，勿增实体 即“简单有效原理”，这句话还是我去年刚来公司的时候和阿赖聊他所说过的 放在项目开发上我的理解是在架构层面要做的尽可能的薄，避免过度设计 这样才有足够的扩展性，灵活性，容错性 这些框架虽好，但是对我们当前业务来说可能过于复杂，比如跨端在之前的阶段还没有这方面需求，而像组件化小程序已经支持，自动化构建我们自己也是可以搭建的并不复杂 相信微信小程序团队 是真正的想把这件事情做好，而且做的是一个生态，不论是小程序对于反馈响应速度，和迭代速度非常给力，还是对开发者社区运营，比如是社区活跃与审核速度挂钩，社区周刊，优质个人和优质企业 对齐web标准，并且更加开放 [图片]                                            小打卡整体架构演进其实小打卡整个架构并非一蹴而就的，就像前面所说的如非必要，勿增实体，而是大量的实际开发中遇到的共同问题解决方案的集合题 [图片]                                            常规架构这个是微信小程序给出的快速开发模版的一个开发模式： server模块提供数据，App作为全局对象直连所有的业务模块，工具函数提供api处理业务模块的需求 优点： 整个模型非常简单，上手快，学习成本 低结构清晰，在业务不复杂的情况下可以快速开发 不瞒大家其实小打卡在最初的半年内基本都是这套模式。 当然是在业务不复杂的情况下，复杂情况下会出现哪些问题呢？ App作为全局对象在有大量业务模块连接的情况下，代码很容易膨胀，在多人开发的时候问题非常明显，无论是fixed bug还是正常的业务开发都会造成麻烦 页面之间独立，缺少公共模块，唯一的工具函数又要尽可能保持单一职责来提供服务（小打卡当时就是因为这个问题导致很多工具函数内部存储直接修改外部状态，导致大量强耦函数合无法拆分） 业务层直连server层，未拆分数据层的情况下，基本不存在复用性 上面所述的问题，从我接手这个项目到真正的调整持续了挺长一段时间，主要是缺乏一个契机来进行优化 优化的转折点 [图片]                                            然后突然有一天产品同学跑过来说： 我们要有自己的核心数据仓库，我们要看实时数据 ok，涉及到数据采集的问题了，我这边从浅到深大概列了几项： 最基础的多个页面pv，uv如何监控，不可能每个页面都要手动收集  为了统计页面和事件的分享和回流的数据，需要在分享事件携带大量的参数 微信的wx.previewImage, wx.chooseImage 等api对于用户session的收集造成很大麻烦 我们先解决第一个问题，如何收集页面pv，uv 容易陷入的误区 [图片]                                            在解决问题之前，我们先说一下开发小程序容易进入的误区 App 和 Page 等函数工厂是微信原生提供，不可修改 小程序项目结构是基于App, Page, 工具函数三个模块构建的 小程序的全局存储只有globalData和本地缓存 其实产生这些误区最根本的原因是小程序没有提供在复杂业务逻辑下的开发范式，比如vue，react有自己的通用开发模版 如果保持这些观念来进行开发的话，很容易将路子走窄，并且难以解决一些实际上的问题， 其实不论小程序和传统web有多少不同， 本质上还是在js环境下开发 小打卡架构图解 [图片]                                            为了更好的方便理解后面的具体实现，我提前放了一张目前小打卡的架构图 首先很熟悉的server这一边垫了一个数据层，主要将数据层和业务层解耦，提高复用性，并且提供一些通用功能，比如返回格式化数据问题，参数校验，日志监控... 在App对象和业务层同样增加了一个全局模块，提供独立于业务和工具类，只提供api之间双向通讯的渠道 工具模块的话其实就是对业务层的增强，比如常见的请求模块，上传模块，路由拦截等等 业务模块的话基本除了增加Component和中间层外没有太大变化 这个图上可能有两块可能大家觉得比较怪异，一个是global里面的函数重载，还有一个是业务模块的中间层是什么？ 函数重载其实就是修改微信提供的App, Page, Component函数，使其更符合我们的业务场景， 业务模块的中间层就是依赖于函数重载的扩展 其实小打卡的整套架构都是基于这两个模块，这两个模块赋予了更多的可能性，然而实现却十分的简单 点击查看：小打卡 | 如何基于微信原生构建应用级小程序底层架构（下）

点击查看：小打卡 | 如何基于微信原生构建应用级小程序底层架构（上）装饰模式[图片]                                            可能有朋友会好奇装饰器和我们接下来要做的原生函数扩展有什么关系？ 先看下装饰模式的定义：在不改变原函数的基础上，附加一些额外的功能 方便更好的理解 创建一个函数，然后将存在originF这个变量里，并对它重新赋值，最后执行，最后的执行直接结果是什么？ hello world!! 这样做的好处是什么，我们对函数f添加了一个新的功能，但是我们没有对原函数进行任何的修改 那么对于小程序的应用 照猫画虎一下，同样的将小程序原生的Page函数存起来，再重新赋值，看下结果，发现Page执行的时候每次都会console这句话，我这里有两个未分包的页面，就执行了2次 [图片]                                            回归到刚开始需要解决的问题，“多个页面pv，uv如何监控，不可能每个页面都要手动收集”， pv怎么算，pv的意思是页面浏览量，也就是需要页面生成时，对应到小程序生命周期就是onLoad 刚才我们做到了每个Page执行时添加功能，但是怎么在onLoad时进行数据统计呢？ 同样的可以用装饰函数修饰page里面的函数方法 [图1] 这个data就是我们实际在pages下写的业务逻辑对象，我们先拿到该页面的key名来进行遍历，首先排除掉非函数，拿到onLoad函数，这时候对它进行扩展，这时候每一个页面执行onLoad的时候都会console一次字符串，当然也可以替换为你想要的任何功能 [图2] 其实我们可以再优化一下，比如抽出一个对象，将你想要装饰的函数写入其中，如果原函数存在则进行装饰，如果不存在则直接赋值，这个抽出来的对象其实可以算是另一种继承方式的实现 它的意义在于[图片]                                            帮助我们开辟了一块公有空间，帮助我们扩展Page对象，并且可以劫持任意方法，在不修改原业务函数代码的情况下增加新的逻辑 其次也是最重要的是，我们完全不需要处理历史包袱 一个应用场景[图片]                                            左边是微信原生的分享方法 遇到的一些问题： 不便于扩展，多个分享策略时，代码块过大，并且分享的通用数据需要每个页面单独处理，例如统计回流信息需要的分享页面信息，事件信息 右边是依赖于我们刚刚开辟的公有空间里填写的公共方法，函数很简单，获得参数，获得页面分享策略，执行，顺便还做了obj转url的处理，避免了纯url书写长路径时的尴尬 思考[图片]                                            既然能扩展Page对象，那么App，Component甚至wx全局对象下的方法呢？ 有兴趣的朋友可以下来想一下 跨页面 / 多页面事件通知[图片]                                            我这边简单提一下跨页面通知的问题，这个应该算是很多小程序开发者遇到的通用问题，我问过的一些人，大部分是使用下面这两种方法，一种是getCurrentPages 页面栈队列，二种onShow upData global里的存储的数据，不管哪一种在业务复杂的情况下都会引起一定的问题，比如第一种的多级入口，第二种的话属于无效判断和及时性 小打卡这边用的简版的event Bus，一个只有80行代码的订阅方法， 左图是一个简单的示例，大致上就是分两种角色，订阅者和发布者，中间依靠任务队列联系，每次发布者推送消息，订阅者都会收到通知和相应的数据 [图片]                                            其实单纯的event bus也有很多的问题，比如：业务复杂情况下过于频繁，对业务代码侵入频繁，可以想像一下到处都是on，off, emit场景 解绑需要树立规范，但是人总是会犯错，容易绑定后忘记解绑或重复绑定的问题，比较浪费内存，对性能也有消耗 结合公共空间我们已知可以对生命周期进行扩展的时候怎么去解决这个问题 其实订阅必然是和页面结合，因为在页面不存在的情况下，发送通知也不会有反馈， 如何证明页面存在自然是onLoad 和 onUnload 按照这个逻辑我们只需要在onLoad和onShow做些处理即可 [图1] 先看右侧业务代码，按照策略注册了一个函数集合，在执行onLoad时，自动将业务内的onRss函数遍历，自定绑定订阅，并推到一个缓存数组内 onUnload时遍历缓存，自动解绑 这时订阅与页面的生命周期强绑定，我们不再需要处理解绑事件，也不需要在业务内插入订阅代码，只需要管理好当前页面的订阅策略即可 技术选型[图片]                                            没有哪一种一定正确的方案，在选型的时候可能需要考虑到上面大致6种元素, 总之选择最适合自己团队方案非常重要 一些小贴士：开发要尽量避免过度设计, 应根据实际需求, 比如之前在写现在这个简版的event bus库的时候设计了很多奇奇怪怪的 功能，现在2年过去还没用到  小程序和浏览器，node本质上是相通的，可以多借鉴和参考 The End今天我的分享就到此结束，算是这段时间对小程序开发上的一点心得体会，谢谢 [图片]                                           

首先你的微信号必须是实名制的，然后注册视频号，认不认证都可以。这个视频号推广个人也可以推广，企业的话目前是跟着认证公众号的类目的，如果公众号的广告主开通不了，那么视频号也无法开通（但是可以以个人身份认证去开通）。 [图片] 然后微信下拉搜索：视频号推广，打开小程序，然后我们去提交资料审核，下面说下审核常遇到的问题： 1、账号头像错误、账号名称错误 这种情况提审情况会经常出现，比如你的头像太暴露，或者视频号名称没什么实质意义。我以我的经历给大家简单说一下，希望大家能看懂。 首先是账号头像错误：这个头像的问题比如太暴露的是不行的，要有实际意义，比如我个人中心丝袜秀那个小程序logo是我的视频号logo，我在申请的时候也被驳回了，说是头像错误。于是我写了个word文档说明了一下这个logo情况，我的目的很明确，我要花钱用视频号带货链接去挂小商店。视频号的这个logo和我小商店的logo是统一的。写完文档后自己打印出来手签字，拍照上传等待审核即可。 [图片] 其次是账号名称错误：比如我的视频号和我在社区的名字是一样的都是CItizenFour，审核的时候被驳回，说我的名字没有实质意义。我又写了个文档，说了一下我这个名字的含义，CItizen是市民的意思，Four是小四的意思，然后取了个谐音翻译出来是小市民。然后我说了下我的这个名字再抖音、快手、微视、B站、CSDN、知乎等大部分平台都是这个名字。然后去提交审核，最后是直接通过了的。 [图片] 总之，我们要写一个文档，加上手签字，说明情况，在行业类型补充资质里上传即可。我自己申请了18个视频号推广，目前全部通过！ 2、视频号内含有其他不适合推广的视频 这个我为了快速提审，把以前审核失败的截图都删了，我大概说一下会遇到什么情况。比如我们在过年的时候在视频号发布过一些红包封面的相关视频，秀自己的红包封面，再或者就是发布过一些营销类型的视频，比如让用户搜索什么小程序，然后干什么。这种审核失败提示解决方案就是，我们把这些违规的视频可以暂时设置为仅自己可见，然后我们再去提交审核。审核通过后可以打开，但是我们不要去给这种视频做推广，100%会审核失败，会导致什么情况我现在也不知道，我不敢去测试，万一封禁我的推广功能咋办？ 3、视频号推广功能 视频号推广审核通过后，我们就可以点击【推广视频】选择视频号发布过的视频进行选择推广，单次推广最低消费100，预计曝光为5000播放量。我们需要提前充值好，直接微信支付充值即可。目前提交视频推广的审核时间大概是3个小时左右，审核通过后就开始扣费推广了。推广期间我们可以暂停推广但是会影响效果，如果推广效果好，可以直接续费无需二次审核。如果想退款可以在推广之前申请退款即可，如果推广正在进行中需要暂停后退款。 视频号直播推广功能目前是需要联系腾讯侧行业运营经理沟通，也不知道去哪儿沟通、和谁沟通，我暂时没有这个渠道。 目前我测试了推广小程序以及小商店，结果还需要等两天，过两天我会发布一下我的推广数据供大家参考。 [图片] 4、视频号推广建议 4-1、目前推广没有任何优惠，我个人觉得第一次推广，或者不定期做些活动，比如8、9折优惠券之类的，应该是可以把这个推广玩儿起来的。 4-2、推广前没有广告预览以及白名单。不像公众号、小程序那样推广之前还能预览一下，还可以设置广告白名单让某个微信号可以看到。 这期就说到这儿，等过几天推广出效果再给大家继续分享！

有经验的开发者都会发现小程序的回掉写法嵌套太深，不利维护； fail忘写，导致白屏异常。对比，部分同学实现了then的写法，却又觉得仍然不够sync。 工欲善其事，必先利其器。 那么推荐个结合了nodejs思想的小工具🔧，await-input，不但适用小程序，也适用Taro、uniapp、微信环境及支付宝环境下的h5，与源代码完美兼容。具体用法https://juejin.cn/post/6904102141229547527或者去看npmjs npm i await-input // 在入口文件引入即可 require('await-input') 或 import('await-input') 基本用法 const [ errInfo, result ] = wx.request.input({url: '', method: ''}); if (!errInfo) { console.log(result); return; } doSomethingWith(result);

h5现在可直接跳转到小程序了吗，可以的话，那位大佬指点一下我吧，我太难了

简介 小程序官方提供的api wx.uploadFile一次只能上传一个文件,一般的解决方案是调用多次，但是存在最大并发限制10，wx-multipart实现了一般的content-type 为 multipart/form-data的post请求。

微信开发者工具作为官方提供的 IDE，集小程序/小游戏运行环境模拟，编辑，编译，调试，版本管理，预览，上传等诸多功能，旨在帮助开发者更好的完成小程序/小游戏的开发工作。 本次分享从编译、调试、流程管理三个方面，主要介绍微信开发者工具的增强编译，自定义预处理命令；企业微信小程序调试、真机调试、多帐号调试；结合 CLI/HTTP 调用搭建持续集成环境、实现自动化测试、以及版本管理等功能。希望通过本次分享，帮助开发者更充分的利用微信开发者工具提供的功能，帮助提升开发效率 iframe class="embed-responsive-item vqq-player" type="text/html" width="640" height="390" src="https://v.qq.com/txp/iframe/player.html?vid=y30062pl393&disableplugin=IframeBottomOpenClientBar&&auto=0" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen>

进行的操作如下图所示: [图片] 打开首页(ID: 3), 此时提前创建 tabbar 栏(ID: 4), 从首页(ID: 3)路由(wx.switchTab)到第二页(ID: 4), 此时提前创建的 tabbar 与第二页的页面ID匹配第二页(ID: 4)提前创建 tabbar 栏(ID: 5)从第二页(ID: 4)路由(wx.switchTab)回首页(ID: 3), 此时还留有一个提前创建 tabbar 栏(ID: 5)从首页(ID: 3)路由到(wx.switchTab)到第三页, 发现此时第三页的ID实却是6, 即跳过了5, 这导致提前创建 tabbar 栏(ID: 5)无法匹配, 进而需要重新创建[图片] 打开首页(ID: 14), 此时提前创建 tabbar 栏(ID: 15), 从首页(ID: 14)路由(wx.switchTab)到第二页(ID: 15), 此时提前创建的 tabbar 与第二页的页面ID匹配第二页(ID: 15)提前创建 tabbar 栏(ID: 16)从第二页(ID: 15)路由(wx.switchTab)回首页(ID: 14), 此时还留有一个提前创建 tabbar 栏(ID: 16)从首页(ID: 14)路由(wx.redirectTo)到一个无 tabbar 的空页面, 发现此空页面的ID为17, 同样跳过了16, 这导致提前创建 tabbar 栏(ID: 16)无法匹配

什么是kbone 微信小程序开发过程中，许多开发者会遇到 小程序 与 Web 端一起的需求，由于 小程序 与 Web 端的运行环境不同，开发者往往需要维护两套类似的代码，这对开发者来说比较耗费力气，并且会出现不同步的情况。 为了解决上述问题，微信小程序推出了同构解决方案 [代码]kbone[代码] 来解决此问题。 那么，[代码]kbone[代码] 要怎么使用呢？这里我们将通过一个 [代码]todo[代码] 的例子来跟大家讲解。 基本结构 首先，我们来看下一个基本的 kbone 项目的目录结构（这里的 [代码]todo[代码] 是基于 [代码]Vue[代码] 的示例，[代码]kbone[代码] 也有 [代码]React[代码]，[代码]Preact[代码]，[代码]Omi[代码] 等版本，详情可移步 kbone github）。 因为 kbone 是为了解决 小程序 与 Web 端的问题，所以每个目录下的配置都会有两份（小程序 与 Web 端各一份） [图片] 入口 不管是 小程序 端还是 Web 端，都需要入口文件。在 [代码]src/index[代码] 目录下，[代码]main.js[代码] 为 Web 端用主入口，[代码]main.mp.js[代码] 则为 小程序 端用主入口。 当然，Web 端会比 小程序 多一个入口页面，即 [代码]index.html[代码]（位于根目录下）。 [图片] 下面两段代码分别是 小程序端 入口与 Web 端入口的代码，可以看到 小程序端的入口代码封装在 [代码]createApp[代码] 函数里面（这里固定即可），内部会比 Web 端多一个创建 [代码]app[代码] 节点的操作，其他的基本就是一致的。 [代码]// 小程序端入口 import Vue from 'vue' import todo from './todo.vue' export default function createApp() { // 创建app节点用于绑定 const container = document.createElement('div') container.id = 'app' document.body.appendChild(container) return new Vue({ el: '#app', render: h => h(todo) }) } [代码] [代码]// web端入口 import Vue from 'vue' import todo from './todo.vue' new Vue({ el: '#app', render: h => h(todo) }) [代码] todo.vue 在上面的入口图可以看到，源码目录中，除了入口文件分开之前，页面文件就是共用的了，这里直接使用 Vue 的写法即可，不用做特殊的适应。 配置 写完代码之后，我们要怎么跑项目呢？这时，配置就派上用场啦。 Web 端配置为正常的 Vue 配置，小程序端配置与 Web 端配置的唯一不同就是需要引入 [代码]mp-webpack-plugin[代码] 插件来将 Vue 组件转化为小程序代码。 [图片] 构建代码 接着，我们需要构建代码，让代码可以运行到各自的运行环境中去。构建完成后，生产代码会位于 dist 目录中。 [代码]// 构建 web 端代码 // 目标代码在 dist/web npm run build // 构建小程序端代码 // 目标代码在 dist/mp npm run mp [代码] 小程序端 的构建会比 Web 端的构建多一个步骤，就是 npm 构建。 进入 [代码]dist/mp[代码] 目录，执行 [代码]npm install[代码] 安装依赖，用开发者工具将 [代码]dist/mp[代码] 目录作为小程序项目导入之后，点击工具栏下的 [代码]构建 npm[代码]，即可预览效果。 效果 最后，我们来看一下 todo 的效果。kbone 初体验，done~ todo 代码可到 kbone/demo13 自提。 [图片] 最后 如果你想了解更多 kbone 相关的使用及详情，可移步 kbone github。 如有疑问，可到 Kbone小主页 发帖沟通。

微信扫码后自动默认创建了账号，还没有绑定手机的时候不小心退出了，然后用手机号注册登入之后想绑定微信提示我微信已绑定账号，微信扫码登录后绑定手机又说手机绑定了另一个账号，现在怎么注销其中一个把两个绑定起来？

[图片] 首先，根据官网文档可以知道 只有非个人 的小程序才可以使用web-view组件，如果你的个人开发者，可以跳过这篇文章。 [图片] 一、使用web-view以及它的好处 1、己方账号（第三方）与小程序openId/UnionId的关联绑定，实现免登陆 比如你是某门户网站S，你要识别自己小程序上的用户与网站用户的关系，你可以通过三种方法绑定关系，公众号，小程序源生，小程序web-view内嵌跳转三种方法 2、内嵌H5的富文本，减少重复开发 比如你是门户网站，社区，以往有大量的新闻和帖子，里面带了各种css样式的富文本，小程序源生是无法直接读取的，需要大量转化，这时候直接内嵌这些H5新闻，大大降低开发成本 3、热更新，减少发布审核 某些需要经常更新的内容、公告、活动页，内嵌H5可以减少频繁提交小程序审核 二、小程序功能赋权 为H5提供各种小程序才有的功能，比如录音，扫一扫等。 注意事项 多场景判断，建议使用官方API： wx.miniProgram.getEnv H5唤醒一些小程序API有一定的延时，0.3~1秒 请调用小程序专用的JSSDK，同一个jssdk，但是webview的功能收到限制，和之前微信打开H5有所不同 小程序自动获取加载H5的title H5中iframe的url必须也是业务域名 web-view一定是撑满全屏的，自定义顶部菜单，悬浮的都没用 三、小程序和H5之前的互相通讯 1、 从小程序 ==>> h5 小程序控制H5，可以直接用src路径传参的形式，比如 [代码]<!-- 小程序端 HTML --> <web-view src="//URL?a=param1&b=param2"></web-view> [代码] 避免在链接中带有中文字符，在 iOS 中会有打开白屏的问题，建议加一下 encodeURIComponent。 2、 从 H5 ==>> 小程序 [图片] 这里我们知道bindmessage是小程序用来监听H5的推送的内容，但是这里不大不小的坑！就是它的三个出发场景： 小程序后退：使用接口名 wx.miniProgram.navigateTo，wx.miniProgram.navigateBack，wx.miniProgram.switchTab 等切换小程序页面/场景的API时候都会出发 分享：这个就是当你点分享小程序的时候，会接受到H5之前发送的postMessage 组件销毁，web-view组件销毁，类似 wx.miniProgram.redirectTo 都会触发。 [代码]<!-- 小程序端 HTML --> <web-view bindmessage="handleGetMessage" src="{{openUrl}}"></web-view> [代码] [代码]// 小程序端 JS --> Page({ /** * 页面的初始数据 */ data: { openUrl: "", }, /** * 获取请求数据 */ handleGetMessage: function (e) { console.log(e.detail.data); } }, }) [代码] [代码]<!-- h5端 HTML和JS --> <script type="text/javascript" src="https://res.wx.qq.com/open/js/jweixin-1.3.2.js"></script> <script> wx.miniProgram.postMessage({ data: { link: "//test.com", title: "一起学习，一起进步" } }); //wx.miniProgram.redirectTo({ // url:"/pages/inner/index?source=123" //}) wx.miniProgram.navigateBack({delta: 1}) </script> [代码] 注意事项 那些H5控制小程序的跳转路径必须是“/”开头，如 “/pages/xxx/xxx”，且路径必须在app.json里有，地址错误的话，有时不报错。 postMessage的json必须是data开始，不然接收不到数据。 [图片] 四、bindmessage接收到消息有3个重要特性(重点) 接收可以是H5之前几分钟前发送postMessage，不一定是即刻发出的。 之前发出的 postMessage的DATA信息会累加，当触发bindmessage接收的时候是一个数组。 [图片] 当bindmessage 再次 接收到数据，之前发送的数据不会被清空，将累加一起返回，获取时要判断好数组的角标 [图片] 五、Tips 1、在IDE工具中如何调试H5 [图片] 可以在 web-view 组件上通过右键 - 调试，打开 web-view 组件的调试。 2、内嵌H5缓存问题 web-view加载的H5具有很重的缓存，如果需要调试，可以通过在url后面加时间戳的方式解决。 3、小程序关闭，H5背景音乐仍然在播放问题 小程序已经关闭，但是H5自带的背景音乐仍然在手机后台播放的问题。这里可以利用一个属性： visibilitychange：页面可见性状态 简单的说，浏览器标签页被隐藏或显示的时候会触发visibilitychange事件。 [代码]var statusBeforeHide = true; //初始化页面的状态 var music = document.getElementById("xxx"); // 更改音乐播放状态 function setChangeMusic() { if (document[hiddenProperty]) { // 页面隐藏 if (statusBeforeHide) { music.pause(); // 暂停 } } else { // 页面显示 if (statusBeforeHide) { music.play() //如果statusBeforeHide是true, 继续播放 } } } let hiddenProperty = ('hidden' in document) ? 'hidden' : ('webkitHidden' in document) ? 'webkitHidden' : ('mozHidden' in document) ? 'mozHidden' : null; if (hiddenProperty) { let visibilityChangeEvent = hiddenProperty.replace(/hidden/i, 'visibilitychange'); let onVisibilityChange = () => { //console.log('visibilityChange'); setChangeMusic(); }; document.addEventListener(visibilityChangeEvent, onVisibilityChange); } else { console.log("不支持这个api"); } [代码] 总结，web-view还是非常实用的组件，且用且珍惜~ 往期回顾： 小程序自定义头部导航栏“完美”解决方案 小程序Canvas生成海报（一） 小程序新版订阅消息+云开发实战与跳坑

应用场景保护野生动物不被人类迫害        野味、奢侈观赏品、皮草、地毯、滋阴补阳药......虽然法律严令禁止，但是仍然有人不惜铤而走险狩猎珍惜濒危野生动物，将他们的生命剥夺，制成一样样供人类消遣的制品。        在公安打击这些涉及野生动物的犯罪的时候，不仅要要和穷凶极恶的犯罪分子斗志斗勇，还要面对形形色色的野生动物活体和制品，而这些野生动物活体和制品的认定，又是整个案件的关键，所以我们的公安小哥哥小姐姐们不仅要去侦查追击破坏生态的坏人们，还要熟练掌握野生动植物识别技术、精通法律知识，做到文武双全，公安小哥哥小姐姐们都疾呼“我太难了”。        野生动植物鉴定的知识内容庞杂，体量巨大，因此培养一个专业的鉴定人员十分不容易，学习过程有7-10年的时间；法律知识同样如此，从一个法律小白到律师大佬，不仅要用几年学习法律基础知识、背诵法律条文、体悟法理，通读法史，还要更长的时间去进行法律实践才能得心应手。        所以利用AI赋能，在传统领域进行去专家化的革新就显得尤为重要也价值巨大，不仅能极大地提高行政效率，更能大大降低诉讼成本，更好地保护可爱的野生动物们，维护一个生机勃勃的地球🌏。 保护我们不被野生动物坑害        什么？？？我们怎么被野生动物迫害？？？        想象一下，夏日午后，你悠闲的在国家森林公园里散步，看青山绿水蝉鸣，望红颜知己笑颜，突然一只猕猴抢了你的午饭！！！还拍拍屁股嘲讽了你。        接着你挥动棒棒将其打残，此🐵气炸一命呜呼，你十分舒爽，你的女伴也拍手称快，这一定是今夜的一大谈资。        但是这时候有人提醒了你，猕猴是国家二级保护动物，猎杀国家二级保护动物构成非法猎捕、杀害珍贵、濒危野生动物罪，根据《野生动物保护法》第三十一条 非法捕杀国家重点保护野生动物的，依照关于惩治捕杀国家重点保护的珍贵、濒危野生动物犯罪的补充规定追究刑事责任。你需要被处五年以下有期徒刑或者拘役，并处罚金；情节严重的，处五年以上十年以下有期徒刑，并处罚金；情节特别严重的，处十年以上有期徒刑，并处罚金或者没收财产。        你：。。。        事实上，这样的法律适用完全正确，但是你的行为也无可厚非，身边真实发生的例子便是2020年7月一大学生卖2只鹦鹉，判刑6年罚款5万的事件。        所以我们该怎么在平时的生活中保护自己？除了珍惜生灵，猴不犯我，我不犯猴，猴若犯我，我也不犯猴，更多我们还可以利用技术手段识别，知晓违法后果，避免踩入雷区。在挥棒前快速地利用小程序查询信息了解情况，敬而远之。 目标用户公安民警、侦查员有野生动物识别需求的普通民众实现思路       8月前识别小程序使用的是传统的C/S模式，服务端大包大揽，但是AI推理模块计算量较大，加上其他的模块，我的学生云真的不堪重负。        所以在8月份我进行了重大版本更新，重写了小程序的代码，基于Paddlejs实现基于边缘计算的移动端识别模式，现在的小程序不需要后台的服务器做计算支撑，直接在小程序端就能完成图片的识别，接着调用云开发函数拉取物种的信息并展示，然后调用云函数把识别结果推送给专业的鉴定员纠察。        此次更新最最最大的好处就是0维护成本😄，白嫖的云服务额度就能维持日常开销，因为用服务端识别模式的时候服务器常常会因为并发量太大而阻塞，更新后用户体验的识别速度也有了很大提升。 架构图       现在除了成本和产品效果的优化以外，因为不用考虑后端的设计，设计复杂度大大降低，但依然需要与其他系统进行交互，比如我需要将识别信息推送到钉钉上，现在的方法是事件钩子，调用云函数完成，还算很省心。              [图片] 效果截图       [图片]         [图片]                      [图片]         [图片] 开源展示      我会在9月中旬在Bilibili上直播介绍整个小程序的数据收集、处理，模型训练、部署，产品开发、优化、部署的全过程并开源代码，感兴趣的同学可以去B站关注飞桨PaddlePaddle，我的微信号xiafanGO-NORTH，希望能借此机会认识更多热爱开发与生活的小伙伴们。代码已在Github开源，开源版本开箱即用，准备好你的AI模型，5分钟构建你的小程序吧！记得点一个star哦~ https://github.com/SOVLOOKUP/PaddlejsInWechat [视频] 作品二维码                                       [图片] 团队介绍       本人大二学生就读于警校，自学前后端、数据挖掘、深度学习技术等等

安卓手机访问接口没有反应

在已配置https的情况下，开发者工具中运行正常，真机调试及体验版 部分接口出现 fail-109:net::ERR_ADDRESS_UNREACHABLE 错误， 部分接口可以正常调用。求大佬告知原因及解决方法！

我们现在有一个电商网站卖的是实物，而采购方都是一些企业，对于这些企业大部分都是使用企业公户银联支付的，那么小程序这一块就只能使用微信支付，一个人的账户支付？有什么办法可以解决这一批B端用户中使用小程序的公户支付的需求？

前言 最近一年多一直在做前端的一些测试，从小程序到店铺装修，基本都是纯前端的工作，刚开始从后端测试转为前端测试的时候，对前端东西茫然无感，而且团队内没有人做过纯前端的测试工作，只能一边踩坑一边总结经验，然后将容易出现问题的点形成体系、不断总结摸索，最终形成了目前的一套前端测试解决方案。在此，将有赞的前端质量保障体系进行总结，希望和大家一起交流。 先来全局看下有赞前端的技术架构和针对每个不同的层次，主要做了哪些保障质量的事情： [图片] [图片] 有赞的 Node 技术架构分为业务层、基础框架层、通用组件和基础服务层，我们日常比较关注的是基础框架、通用组件和业务层代码。Node 业务层做了两件事情，一是提供页面渲染的 client 层，用于和 C 端用户交互，包括样式、行为 js 等；二是提供数据服务的 server 层，用于组装后台提供的各种接口，完成面向 C 端的接口封装。 对于每个不同的层，我们都做了一些事情来保障质量，包括： 针对整个业务层的 UI 自动化、核心接口|页面拨测； 针对 client 层的 sentry 报警； 针对 server 层的接口测试、业务报警； 针对基础框架和通用组件的单元测试； 针对通用组件变更的版本变更报警； 针对线上发布的流程规范、用例维护等。 下面就来分别讲一下这几个维度的质量保障工作。 一、UI 自动化 很多人会认为，UI 自动化维护成本高、性价比低，但是为什么在有赞的前端质量保证体系中放在了最前面呢？ 前端重用户交互，单纯的接口测试、单元测试不能真实反映用户的操作路径，并且从以往的经验中总结得出，因为各种不可控因素导致的发布 A 功能而 B 功能无法使用，特别是核心简单场景的不可用时有出现，所以每次发布一个应用前，都会将此应用提供的核心功能执行一遍，那随着业务的不断积累，需要回归的测试场景也越来越多，导致回归的工作量巨大。为了降低人力成本，我们亟需通过自动化手段释放劳动力，所以将核心流程回归的 UI 自动化提到了最核心地位。 当然，UI 自动化的最大痛点确实是维护成本，为降低维护成本，我们将页面分为组件维度、页面维度，并提供统一的包来处理公用组件、特殊页面的通用逻辑，封装通用方法等，例如初始化浏览器信息、环境选择、登录、多网点切换、点击、输入、获取元素内容等等，业务回归用例只需要关注自己的用例操作步骤即可。 1、框架选择 – puppeteer[1]，它是由 Chrome 维护的 Node 库，基于 DevTools 协议来驱动 chrome 或者 chromium 浏览器运行，支持 headless 和 non-headless 两种方式。官网提供了非常丰富的文档，简单易学。 UI 自动化框架有很多种，包括 selenium、phantom；对比后发现 puppeteer 比较轻量，只需要增加一个 npm 包即可使用；它是基于事件驱动的方式，比 selenium 的等待轮询更稳当、性能更佳；另外，它是 chrome 原生支持，能提供所有 chrome 支持的 api，同时我们的业务场景只需要覆盖 chrome，所以它是最好的选择。 – mocha[2] + mochawesome[3]，mocha 是比较主流的测试框架，支持 beforeEach、before、afterEach、after 等钩子函数，assert 断言，测试套件，用例编排等。 mochawesome 是 mocha 测试框架的第三方插件，支持生成漂亮的 html/css 报告。 js 测试框架同样有很多可以选择，mocha、ava、Jtest 等等，选择 mocha 是因为它更灵活，很多配置可以结合第三方库，比如 report 就是结合了 mochawesome 来生成好看的 html 报告；断言可以用 powser-assert 替代。 2、脚本编写 封装基础库 封装 pc 端、h5 端浏览器的初始化过程 封装 pc 端、h5 端登录统一处理 封装页面模型和组件模型 封装上传组件、日期组件、select 组件等的统一操作方法 封装 input、click、hover、tap、scrollTo、hover、isElementShow、isElementExist、getElementVariable 等方法 提供根据 “html 标签>>页面文字” 形式获取页面元素及操作方法的统一支持 封装 baseTest，增加用例开始、结束后的统一操作 封装 assert，增加断言日志记录 业务用例 安装基础库 编排业务用例 3、执行逻辑 分环境执行 增加预上线环境代码变更触发、线上环境自动执行 监控源码变更 增加 gitlab webhook，监控开发源码合并 master 时自动在预上线环境执行 增加 gitlab webhook，监控测试用例变更时自动在生产环境执行 每日定时执行 增加 crontab，每日定时执行线上环境 [图片] [图片] [图片] [图片] 二、接口测试 接口测试主要针对于 Node 的 server 层，根据我们的开发规范，Node 不做复杂的业务逻辑，但是需要将服务化应用提供 dubbo 接口进行一次转换，或将多个 dubbo 接口组合起来，提供一个可供 h5/小程序渲染数据的 http 接口，转化过程就带来了各种数据的获取、组合、转换，形成了新的端到端接口。这个时候单单靠服务化接口的自动化已经不能保障对上层接口的全覆盖，所以我们针对 Node 接口也进行自动化测试。为了使用测试内部统一的测试框架，我们通过 java 去请求 Node 提供的 http 接口，那么当用例都写好之后，该如何评判接口测试的质量？是否完全覆盖了全部业务逻辑呢？此时就需要一个行之有效的方法来获取到测试的覆盖情况，以检查有哪些场景是接口测试中未覆盖的，做到更好的查漏补缺。 – istanbul[4] 是业界比较易用的 js 覆盖率工具，它利用模块加载的钩子计算语句、行、方法和分支覆盖率，以便在执行测试用例时透明的增加覆盖率。它支持所有类型的 js 覆盖率，包括单元测试、服务端功能测试以及浏览器测试。 但是，我们的接口用例写在 Java 代码中，通过 Http 请求的方式到达 Node 服务器，非 js 单测，也非浏览器功能测试，如何才能获取到 Node 接口的覆盖率呢？ 解决办法是增加 cover 参数：–handle-sigint，通过增加 --handle-sigint 参数启动服务，当服务接收到一个 SIGINT 信号（linux 中 SIGINT 关联了 Ctrl+C），会通知 istanbul 生成覆盖率。这个命令非常适合我们，并且因此形成了我们接口覆盖率的一个模型： [代码]1. istanbule --handle-sigint 启动服务 2. 执行测试用例 3. 发送 SIGINT结束istanbule，得到覆盖率 [代码] 最终，解决了我们的 Node 接口覆盖率问题，并通过 jenkins 持续集成来自动构建 [图片] [图片] [图片] 当然，在获取覆盖率的时候有需求文件是不需要统计的，可以通过在根路径下增加 .istanbule.yml 文件的方式，来排除或者指定需要统计覆盖率的文件 [代码]verbose: false instrumentation: root: . extensions: - .js default-excludes: true excludes:['**/common/**','**/app/constants/**','**/lib/**'] embed-source: false variable: __coverage__ compact: true preserve-comments: false complete-copy: false save-baseline: false baseline-file: ./coverage/coverage-baseline.json include-all-sources: false include-pid: false es-modules: false reporting: print: summary reports: - lcov dir: ./coverage watermarks: statements: [50, 80] lines: [50, 80] functions: [50, 80] branches: [50, 80] report-config: clover: {file: clover.xml} cobertura: {file: cobertura-coverage.xml} json: {file: coverage-final.json} json-summary: {file: coverage-summary.json} lcovonly: {file: lcov.info} teamcity: {file: null, blockName: Code Coverage Summary} text: {file: null, maxCols: 0} text-lcov: {file: lcov.info} text-summary: {file: null} hooks: hook-run-in-context: false post-require-hook: null handle-sigint: false check: global: statements: 0 lines: 0 branches: 0 functions: 0 excludes: [] each: statements: 0 lines: 0 branches: 0 functions: 0 excludes: [] [代码] 三、单元测试 单元测试在测试分层中处于金字塔最底层的位置，单元测试做的比较到位的情况下，能过滤掉大部分的问题，并且提早发现 bug，也可以降低 bug 成本。推行一段时间的单测后发现，在有赞的 Node 框架中，业务层的 server 端只做接口组装，client 端面向浏览器，都不太适合做单元测试，所以我们只针对基础框架和通用组件进行单测，保障基础服务可以通过单测排除大部分的问题。比如基础框架中店铺通用信息服务，单测检查店铺信息获取；比如页面级商品组件，单测检查商品组件渲染的 html 是否和原来一致。 单测方案试行了两个框架： Jest[5] ava[6] 比较推荐的是 Jest 方案，它支持 Matchers 方式断言；支持 Snapshot Testing，可测试组件类代码渲染的 html 是否正确；支持多种 mock，包括 mock 方法实现、mock 定时器、mock 依赖的 module 等；支持 istanbule，可以方便的获取覆盖率。 总之，前端的单测方案也越来越成熟，需要前端开发人员更加关注 js 单测，将 bug 扼杀在摇篮中。 四、基础库变更报警 上面我们已经对基础服务和基础组件进行了单元测试，但是单测也不能完全保证基础库的变更完全没有问题，伴随着业务层引入新版本的基础库，bug 会进一步带入到业务层，最终影响 C 端用户的正常使用。那如何保障每次业务层引入新版本的基础库之后能做到全面的回归？如何让业务测试同学对基础库变更更加敏感呢？针对这种情况，我们着手做了一个基础库版本变更的小工具。实现思路如下： [代码]1. 对比一次 master 代码的提交或 merge 请求，判断 package.json 中是否有特定基础库版本变更 2. 将对应基础库的前后两个版本的代码对比发送到测试负责人 3. 根据 changelog 判断此次回归的用例范围 4. 增加 gitlab webhook，只有合并到合并发布分支或者 master 分支的代码才触发检查 [代码] 这个小工具的引入能及时通知测试人员针对什么需求改动了基础组件，以及这次基础组件的升级主要影响了哪些方面，这样能避免相对黑盒的测试。 第一版实现了最简功能，后续再深挖需求，可以做到前端代码变更的精准测试。 [图片] 五、sentry 报警 在刚接触前端测试的时候，js 的报错没有任何追踪，对于排查问题和定位问题有很大困扰。因此我们着手引入了 sentry 报警监控，用于监控线上环境 js 的运行情况。 – sentry[7] 是一款开源的错误追踪工具，它可以帮助开发者实时监控和修复崩溃。 开始我们接入的方式比较简单粗暴，直接全局接入，带来的问题是报警信息非常庞大，全局上报后 info、warn 信息都会打出来。 更改后，使用 sentry 的姿势是： sentry 的全局信息上报，并进行筛选 错误类型: TypeError 或者 ReferenceError 错误出现用户 > 1k 错误出现在 js 文件中 出现错误的店铺 > 2家 增加核心业务异常流程的主动上报 最终将筛选后的错误信息通过邮件的形式发送给告警接收人，在固定的时间集中修复。 [图片] [图片] 六、业务报警 除了 sentry 监控报警，Node 接口层的业务报警同样是必不可少的一部分，它能及时发现 Node 提供的接口中存在的业务异常。这部分是开发和运维同学做的，包括在 Node 框架底层接入日志系统；在业务层正确的上报错误级别、错误内容、错误堆栈信息；在日志系统增加合理的告警策略，超过阈值之后短信、电话告警，以便于及时发现问题、排查问题。 业务告警是最能快速反应生产环境问题的一环，如果某次发布之后发生告警，我们第一时间选择回滚，以保证线上的稳定性。 七、约定规范 除了上述的一些测试和告警手段之外，我们也做了一些流程规范、用例维护等基础建设，包括： 发布规范 多个日常分支合并发布 限制发布时间 规范发布流程 整理自测核心检查要点 基线用例库 不同业务 P0 核心用例定期更新 项目用例定期更新到业务回归用例库 线上问题场景及时更新到回归用例库 目前有赞的前端测试套路基本就是这样，当然有些平时的努力没有完全展开，例如接口测试中增加返回值结构体对比；增加线上接口或页面的拨测[8]；给开发进行自测用例设计培训等等。也还有很多新功能探索中，如接入流量对比引擎，将线上流量导到预上线环境，在代码上线前进行对比测试；增加UI自动化的截图对比；探索小程序的UI自动化等等。 参考链接 [1] https://github.com/GoogleChrome/puppeteer [2] https://www.npmjs.com/package/mocha [3] https://www.npmjs.com/package/mochawesome [4] https://github.com/gotwarlost/istanbul [5] https://github.com/facebook/jest [6] https://github.com/avajs/ava [7] https://docs.sentry.io [8] https://tech.youzan.com/youzan-online-active-testing/

我在商户后台创建了满减代金券，同样商户ID的小程序支付时没有自动显示满减券，但是微信支付商业码扫码支付时会显示自动满减抵扣，小程序这边的支付要自动抵扣需要开发吗？

移动应用：AppID：wx77258483fe6d6d4b 小程序：APPID：wx690bdc96f12e48f2 已经绑定在同一开放平台下了，开放平台账号：kjb_api@163.com 小程序端 unionid:oB4-5wQiOnl_BhCTB0idQpUBcT_A ， openid:oPj-q5TauesGAVmW-bPrDvAuMqcQ 移动应用 unionid：oB4-5wbWzAcgW8aGpLZMhtm6DRF0 ，openid:ov_6Wv5qxM6U-LLKixLR_YmJQpNk 麻烦官方帮忙查一下，谢谢

[图片] 手机型号Nove 5 pro，小程序页面底部出现完成字样有点像按钮，代码里没有写任何“完成”的字样或者button

[图片] 如果买来的小程序只是一个名字、一个商城、一个在微信中永远也找不到的应用，那你为什么还要去花这份钱？作为资深小程序技术开发服务商，云店加商城发现，尽管越来越多的商家开始认识到小程序快速、低成本获客的优势，但制作出的小程序却徒具其形，并没有真正运营起来，导致小程序并没有给自己带来实实在在的受益。 为此，云店加商城整理了一份涵盖小程序前期准备及上线初、中期的日常运营方案，让即使没有线上电商操作经验的商家也能快速上手小程序。 小程序营销功能配置 作为云店加商城的小程序客户，无论是总部服务人员还是分布在全国各地的代理商，在交付小程序时，都会在小程序前端页面配置好所有营销功能：优惠券、会员卡、秒杀、拼团、满减、礼品卡和全员分销。 商家在小程序上线前，首先要明确一件事：这些营销功能是不是都要放在首页。在自身所在行业中，哪些营销功能更受用户青睐。比如拼团更适合水果生鲜、秒杀多用于服装服饰、礼品卡在美容美发中更为常见，商家用把最吸引用户的营销功能放在最显眼的位置。 微信工具配置工作 即使经验再丰富的小程序开发商交付的产品也并不一定完全契合用户需求，商家一定要对小程序页面布局做二次优化，让用户进入后第一眼就“爱上”自己的小程序。除此之外，商家应该配合小程序运营对微信其他生态工具做一系列配置。 1、附近的小程序：让店铺周边的用户可以找到你。 2、小程序关键词：让用户在微信中可以更好的搜到你。 3、绑定公众号：公众号是小程序的根据地，通过绑定小程序，可以在自定义菜单、图文消息中进入小程序，为小程序引流。。 4、支付关注公众号：担心小程序用户“用完即走”？ 上线初期运营工作 云店加商城建议广大商家，小程序想要做得好，一定是“公众号+社群+小程序”联动的方式，从目前来看，电商移动化、社交化趋势明显，商家应早做布局。 当小程序正式上线后，商家应当有以下几个运营动作：上线新人零门槛优惠券，让用户快速体验商品和服务；定期上线秒杀，提升用户复购率；长期有拼团，让老客户可以源源不断带来新用户。在日常运营中，商家应做到每天有秒杀、每周有拼团，定期有满减。 而作为商家不熟悉的社群运营，云店加商城建议可以这么做：在云店加小程序营销中心的会员管理以及订单中可以查到用户的手机号，把每位购买用户都尝试拉群，然后在群中定期做晒单分享、促销通知、商品使用技巧等分享活动。 目前，小程序渗透到人们衣食住行的方方面面，对商家而言，如同PC互联网时代，每个企业必须有一个网站，在移动互联网时代，小程序同样会成为企业标配。 受益于云店加商城推出的O2O小程序，借助会员卡、优惠券、拼团、秒杀、满减、全员分销等多样社交营销模块，商家可以让用户可以快速了解、体验产品和服务，推动行业线上线下渠道融合，提升新用户吸引、活跃、转化的效率。

就象这样： [图片] [图片] js里： data: { rect: wx.getMenuButtonBoundingClientRect() }, wxml里 <image src="../../image/timg.png" mode="widthFix" style="width:{{rect.width+80}}px;position:fixed;z-index:9;left:{{rect.left-28}}px;top:-12px"></image> <view class="card"> </view>

自定义顶部标题和左上角按钮方法解析及实践 前言 之前有兄台发过设置custom的方法 但是没有具体的实现方法 以至于很多不了解小程序的开发者不能循序渐进的理解制作自定义标题的方法 在这里详细总结了计算各参数的方法 我也写了一个自定义标题组件 只需要引用 直接在页面中调用即可 但因为掺杂了业务代码 需要整理过后会放出来 具体方法 首先在app.json中 将window.navigateionStyle 设置为custom [图片] 使用 wx.getSystemInfoSync 获取系统的属性 其中有顶部状态栏的高度 使用 wx.getMenuButtonBoundingClientRect 获取右上角胶囊菜单的相关属性 包括胶囊菜单的高度、相距上下左右屏幕的绝对位置 [图片] 如上图 我们需要获取四个参数 来确定整个标题栏的各项参数和左侧自定义胶囊的位置 获取顶部状态栏高度sys.statusBarHeight 具体代码 [代码]var sys= wx.getSystemInfoSync() var menu = wx.getMenuButtonBoundingClientRect() var statusHeight = menu.statusBarHeight var titleHeight = menu.height var titleRowWidth = sys.right - menu.right var titleColumnHeight = menu.top - menu.statusBarHeight [代码] 注意 小程序原生组件会遮挡自定义头部组件 如 canvas组件 input textarea的提示信息placeholder 该问题可以使用cover-view将头部定义为原生组件 设置层级解决 20191125后续更新 wx.getMenuButtonBoundingClientRect()返回undefined的情况 wx.getMenuButtonBoundingClientRect()在安卓和IOS端均会出现获取不到值的情况（返回undefined） 官方给出的答案是已经修复了该问题 但实际测试还是会出现类似问题 该问题与 平台 和 微信基础库 （随微信版本更新）无关 导致我们无法获取胶囊按钮的属性 进而无法计算header的高度 该问题极难复现 我在自己的真机上遇到过2次 在我的应用中出现概率不到1% 应对方法1: 官方建议延迟100MS 或 在返回undefined的情况下 重新获取一次 应对方法2: 判断平台 给与预估的默认值 IOS端和不同安卓端 IOS各机型的高度为44px 安卓端我测试最多的情况是48px 但安卓端实际情况需要具体测试 做进一步兼容 代码如下 [图片] 这里wx.getMenuButtonBoundingClientRect()方法在低版本微信中是不能用的 而且低版本的微信中不能使用wx.canIUse方法判断该方法是否存在 因此用捕获错误的方式兼容 在menu的属性返回undefined时 用我们预估的值去兼容 另外github.com有一个通过手机型号 返回手机各项参数的库 其中一项就是头部状态栏的高度 如果你想更准确的适配更多机型 可以使用这个库 无论哪种方法都不是最优的解决方案 大家酌情按照场景进行适配