wx.getLocation官方API调用后，没有任何回调，success和fail方法都不执行。部分手机偶现，每天都会有客户反馈。

调用getLocation 获取位置信息最近频繁超时， 请问是什么原因？ [图片]

wx.getLocation在调用后，无任何回调，success及fail均未收到回调数据，现象为getLocation定位API假死。 基础库版本：3.3.5 用户日志已上传，日志时间范围：03月30日 17:00～03月30日 18:00 用户日志微信号：diuzuiwang

问题： wx.getLocation定位失败， 因为使用了showLoading，用户那边一直在转圈。官方帮忙赶紧看下，越来越多用户出现，抱怨声很大。 用户反馈： 几乎每天都会出现，重启手机也不行，网络信号都满格 wx.showLoading({ title: '正在获取位置'});  wx.getLocation({     type: 'gcj02',     isHighAccuracy:false,     highAccuracyExpireTime: 3100,     success: function (res) {       wx.hideLoading();       //success..     },     fail: function (res) {       wx.hideLoading();       //fail...     }  }) [图片] [图片]

安卓 wx.getLocation  定位不了，一直显示定位中，不进入任何回调？

[图片][图片][图片][图片]

wx.getLocation在调用后，无任何回调，success及fail均未收到回调数据，点右上角的···拉起菜单后，一直显示正在定位中，怎样都无法获取到定位信息 基础库版本:3.4.3 用户日志已上传，日志时间范围: 04月27日 22:00~04月27日 23:00 04月28日 08:00~04月28日 09:00 用户日志微信号: JiaZou1993

常见于安卓用户，有时候可以取到 有时候取不到 现在解决办法通过 加个定时 超过5s 判定获取失败，为什么会有获取失败的情况呢，userLocation的权限已经给了

小程序模板库文档： https://developers.weixin.qq.com/doc/oplatform/Third-party_Platforms/2.0/operation/thirdparty/template.html 按照以上文档说明可知：如果是标准模板库，则 ext.json 文件仅支持的参数 extAppid / ext / window 也就是说，标准模板库不支持 extEnable 参数，既然不支持，那么 ext.json 文件实际就无法生效 正因为 ext.json 文件实际无效， wx.getExtConfigSync 或者 wx.getExtConfig 实际上也无效，获取不到自定义字段 ext 配置信息。 那么这时仅支持的三个参数 extAppid / ext / window 有何意义？

第三方平台提审小程序后撤回，提审额度会恢复吗？

通过接口 获取到这个月提审额度为0 ，这样直接导致我无法提交第三方小程序审核，请问是什么情况？是不是我哪里出错了？请帮忙解决一下，急！！！谢谢

第三方平台的提审额度，当月次数未用完会顺延到下一个月吗？还是说每个月的额度按照表现重新分配的？

小程序审核的时候，提示“近7天提交审核的小程序数量过多，请耐心等待审核完毕后再次提交”，导致整个平台的下小程序提审都受该问题影响，已经发送增加额度邮件，能否加急处理下？ 第三方平台APPID:wx2d2589567e7b9e97

第三方平台APPID：wxcefa1343c4711090 当月剩余提审额度：0 需求： 由于小程序用户信息相关接口调整。需要对所有小程序进行调整升级，希望额度提高为 300，感谢 已经提交邮件申请，但没有得到回复

第三方平台开发的小程序标准模板已审核通过，然后标准模板提交小程序审核后有申请了加急审核申请 加急审核申请的时候有提示 “本月加急额度已用完，请提高提审质量以获取更多额度” ，目前我一次也没有加急过小程序 ，怎么回事儿 第三方平台APPID：wx863f652e989d78ef 第三方平台账号：747100407@qq.com

第三方平台服务商，中午查询提审额度有4700，现在查询额度只有20，在提审的过程中，突然就不能提审了，提示达到额度限制

目前的可用额度为0 了，现在有几个急需提交审核，已发送邮件，希望尽快审核一下，谢谢！

随着小程序服务商生态的壮大和平台面向服务商提审机制的优化，现阶段小程序服务商的提升质量有了稳步的提升，考虑到服务商自身业务的拓展对提审额度提升的效率及数量需求，为鼓励服务商拓展商户新增业务，平台对当前提审额度的限制能力进行优化：对在平台注册的第三方小程序首单提审不做quota限制，详细规则如下： 1） 第三方小程序属于首次在小程序平台内提审时不消耗提审quota 2） 当月quota已用完的情况下，属于首单提审的不受限制，可以继续提审 3） 首次提审后撤回再次提审仍算首单提审，但第二次撤回后，再次提审就不能享受这个政策 备注：即使小程序是首次授权给服务商的第一次提审，如在授权前已经自行提审或者被别的服务商提审过，则不算首单。 友情提示：部分服务商在商家注册时有自动提审机制，此时商家的内容往往未配置完全，容易驳回，请加强对商家提审的控制，避免浪费首单提审机会。 Quota基于服务商提审质量分配的原则依然不变，此外，被平台评估为滥用首单机制的服务商，将会被限制该能力，各服务商需要继续关注对商户的运营和控制，减少驳回和违规情况。 未来我们会针对服务商提供更多的激励，如平台评价优秀的小程序提审不消耗quota且审核优先安排等措施，期待第三方服务商和平台能建立良好的生态合作共赢关系，帮助商户通过小程序为更多的用户提供更优质的服务。

第三方服务商按月按提审表现分配提审限额（quota）的机制上线以来，服务商对提审质量的重视度不断上升，大盘提审合格率也不断提升。为了保障服务商提审效率，携手与服务商共同发展，平台近期将完善quota机制，更科学合理地分配服务商提审额度。 一、提审限额分配机制优化 服务商表现排名，会综合服务商的以下表现进行评价。同时平台考察服务商表现维度更全面（11月在服务商助手小程序的“表现与权益”专区上线） 月quota分配优化前：月quota基于近3月提审单数、服务商表现排名分配月quota分配优化后：月quota基于近6月提审单数、服务商表现排名分配新服务商支持：新第三方服务商每月最少可获得50个quota。*新第三方服务商定义：自上线之日起一年内称之为新第三方服务商 安全：提审质量、线上违规情况、低风险小程序数量、高风险小程序数量等 规模：授权小程序个数、主体个数、月新增小程序个数等 活跃：高活跃小程序个数及占比、不活跃小程序个数及占比 支付：支付金额、笔数、支付活跃小程序个数及占比 体验：体验差小程序个数及占比 [图片] 二、quota自助调额范围优化： 优化前：服务商每次申请临时额度为月初分配提审额度的15%优化后：月初分配的quota作为调额范围的划分标准，具体调整范围如下图：[图片] 特别注意： 服务商在可选范围内按需求自助调额，自助调整次数以及调额范围将基于提审合格率、quota消耗率等服务商表现分配，分配规则如下： 自然年内若存在超过三个月（不含）提审合格率低于80%，将无法申请临时调额quota消耗率作为第三方服务商画像分值的一个重要参考项，请按需进行quota调额申请，若quota消耗率存在超过三个月（不含）低于60%，服务商的画像分值排序将会降低，影响后续审核的优先级以及quota等权益分配。quota消耗率指当月quota使用值/（当月quota分配值+临时申请quota总值）*100% [图片] 平台将持续为服务商提供高效快捷审核服务，若因业务发展等情况存在超额提审需求的服务商还可以通过“小程序服务商助手-我的-咨询反馈”联系人工客服进行申请更多临时额度，客服工作时间：工作日：9:00-12:00,14:00-18:00，特殊时期以平台公告为准。 临时额度人工申请周期为1-3天，请服务商提前规划好提审额度的需求。 微信开放平台运营团队 2020.11.4

第三方开发平台服务商这个月没有额度，都是申请的零时额度，额度不够

[图片]主要还有另外：符合一定条件，这个有点模糊

小程序第三方平台模板库的标准模板库和普通模板库的疑问extEnable决定 ext.json 是否生效  那么标准模板中extEnable不支持的情况下   还能否取到  ext:{mchid:'xxx'}里的数据， [图片] 另外这个extEnable默认是生效还是不生效

第三方平台APPID：wx1f18d5757ce18cf5 (1):你好，小程序【发现】页面无具体运营内容，请上架正式内容或商品（非测试）后重新提交审核。 为什么每次都提示这个，你们审核的时候我们获取不到 APPID吗？

[图片] 都提审一个多月了还是在审核中，请问啥是原因？ 现在整个流程都卡主了

我在web后台讲一个草稿模板添加到标准模板库, 然后发布到多个小程序 提交审核并且通过之后, 标准模板库的代码,还是显示 "待提审"状态, 点击提交审核之后填写了相关内容, 确定之后 页面还是 显示待提审. 是我操作的有问题吗? [图片] [图片] 就在我截图的时候 突然有反馈了, 是我刚巧遇到服务维护吗????? [图片]

（一）我是有货源的商家● 第一步：开通小商店或小程序（需接入自定义版交易组件）开通非个人主体的小商店：小商店开店指引开通非个人主体的小程序并接入自定义版交易组件：自定义版交易组件接入指引● 第二步：成为具有视频号商品上架能力的店铺成员我开通的是小商店：我添加的店长、店员、导购员、推广员等店铺成员均可以添加小商店的商品信息到其视频号；我开通的是小程序：需要小程序（含小商店）开发者先将创作者添加为“视频号推广员”。（操作步骤：商家在微信公众平台添加创作者视频号为推广员），添加成功后，创作者可以在其视频号商品橱窗内添加该小程序的商品。[图片] ● 第三步：添加商品至视频号商铺橱窗在微信发现页-视频号-创作者中心-带货中心-橱窗管理-添加商品-选择通过小商店/小程序添加商品。[图片] （二）我是商家想找视频号创作者通过短视频分享商品●我是小商店商家方式一 接入小商店联盟：小商店商家可以接入小商店联盟，具体可参考小商店联盟接入文档：小程序联盟（小商店版）商家入驻文档。商家接入后，创作者可以在「视频号选品中心」、「小程序联盟」、「小商店助手—我要带货」等途径通过商品名称&商品ID搜索到对应的商品。[图片] 方式二 小商店推广员：在「小商店PC端后台—推广中心—视频号推广」功能下，将视频号创作者添加为店铺的视频号推广员。添加成功后，创作者可在其视频号商品橱窗内添加该小商店的商品。（注：平台将不对「推广员」进行计佣结算，需要商家自行与创作者商议结算）[图片] ●我是小程序商家方式一 接入小程序联盟：已接入自定义交易组件的商家可以接入小程序联盟，具体可参考小程序联盟接入文档。商家接入后，创作者可以在「视频号选品中心」、「小程序联盟」、「小商店助手—我要带货」等途径通过商品名称&商品ID搜索到对应的商品。[图片] 方式二 小程序推广员：需要小程序开发者先将视频号创作者添加为“视频号推广员”。（操作步骤：商家在微信公众平台添加视频号创作者为推广员），添加成功后，创作者可以在其视频号商品橱窗内添加该小程序的商品。（注：平台将不对「推广员」进行分佣结算，需要商家自行与创作者商议结算）[图片]

为提升第三方代开发小程序的代码审核体验，平台对授权服务商代开发的小程序上线“标准模板“审核流程，使用标准模板且满足条件的小程序可加速通过审核，具体如下： 一、 支持小程序范围 适用于通过标准模板代开发，且完成自定义版交易组件接入的小程序二、 审核流程 第三方需先提审标准模板，获得审核通过的标准模板 [图片] 授权给第三方代开发的小程序使用审核通过的标准模板，进行小程序代码提审，提审后进入“标准模板小程序”审核队列（标准模板未通过小程序会触发自动驳回）。进入“标准模板小程序”审核队列的小程序，同时满足如下条件时审核结果为通过。1.小程序配置的服务类目属于其标准模板已审核通过的类目（如：标准模板审核通过a/b/c/d四个类目，小程序配置了b/c两个类目，则视为符合条件）。可通过获取模板列表接口标准模板配置的服务类目信息。 2.小程序已经完成自定义版交易组件接入。可通过获取接入状态接口返回的access_info字段进行判断，access_info的参数项都返回1则视为接入完成。 3.满足小程序代码审核的其他要求和规范。详情查看：https://developers.weixin.qq.com/miniprogram/product/reject.html

标准模板审核，模板ID：14，提审时间：2022-01-06 14:32，到目前为止已接近9个工作日还在审核中，请确认下目前进度以及审核时间超长的原因？ 

第三方平台标准模板审核通过后有abcd四个类目，第三方小程序提交的时候有cdef四个类目，这种小程序是等待人工审核，还是审核不通过？

[图片][图片]

小程序获取设备唯一标识

今儿上架一个碘伏棉签 给驳回了 理由是禁售商品 碘伏是处方药么？或者药品？ 不知道在哪里咨询 客服都是机器人 有人能回答一下么 （占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数占位符凑字数）

背景 我们发现大部分小程序都会使用 [代码]wx.getUserInfo[代码] 接口，来获取用户信息。原本设计这个接口时，我们希望开发者在真正需要用户信息的情况下才去调取这个接口，但很多开发者会直接调用这个接口，导致用户在使用小程序的时候产生困扰，归结起来有几点： 开发者在小程序首页直接调用 [代码]wx.getUserInfo[代码] 进行授权，弹框获取用户信息，会使得一部分用户点击“拒绝”按钮。 在开发者没有处理用户拒绝弹框的情况下，用户必须授权头像昵称等信息才能继续使用小程序，会导致某些用户放弃使用该小程序。 用户没有很好的方式重新授权，尽管我们增加了[代码]设置[代码]页面，可以让用户选择重新授权，但很多用户并不知道可以这么操作。 此外，我们发现开发者默认将 [代码]wx.login[代码] 和 [代码]wx.getUserInfo[代码] 绑定使用，这个是由于我们一开始的设计缺陷和实例代码导致的（[代码]wx.getUserInfo[代码] 必须通过 [代码]wx.login[代码] 在后台生成 [代码]session_key[代码]后才能调用）。同时，我们收到开发者的反馈，希望用户进入小程序首页便能获取到用户的 [代码]unionId[代码]，以便识别到用户是否以前关注了同主体公众号或使用过同主体的App 。 为了解决以上问题，针对获取用户信息我们更新了三个能力： 1.使用组件来获取用户信息 2.若用户满足一定条件，则可以用[代码]wx.login[代码] 获取到的[代码]code[代码]直接换到[代码]unionId[代码] 3.[代码]wx.getUserInfo[代码] 不需要依赖 [代码]wx.login[代码] 就能调用得到数据 获取用户信息组件介绍 [代码][代码] 组件变化： [代码]open-type [代码]属性增加 [代码]getUserInfo[代码] ：用户点击时候会触发 [代码]bindgetuserinfo[代码] 事件。 新增事件 [代码]bindgetuserinfo[代码] ：当 [代码]open-type[代码]为 [代码]getUserInfo[代码] 时，用户点击会触发。可以从事件返回参数的 [代码]detail[代码] 字段中获取到和 [代码]wx.getUserInfo[代码] 返回参数相同的数据。 示例： [代码]<button open-type="getUserInfo" bindgetuserinfo="userInfoHandler"> Click me button>[代码]和 [代码]wx.getUserInfo[代码] 不同之处在于： 1.API [代码]wx.getUserInfo[代码] 只会弹一次框，用户拒绝授权之后，再次调用将不会弹框； 2.组件 [代码][代码][代码][代码] 由于是用户主动触发，不受弹框次数限制，只要用户没有授权，都会再次弹框。 通过获取用户信息的组件，就可以解决用户再次授权的问题。 直接获取unionId开发者申请 [代码]userinfo[代码] 授权主要为了获取 [代码]unionid[代码]，我们鼓励开发者在不骚扰用户的情况下合理获得[代码]unionid[代码]，而仅在必要时才向用户弹窗申请使用昵称头像。为此，凡使用“获取用户信息组件”获取用户昵称头像的小程序，在满足以下全部条件时，将可以静默获得 [代码]unionid[代码]： 1.在微信开放平台下存在同主体的App、公众号、小程序。 2.用户关注了某个相同主体公众号，或曾经在某个相同主体App、公众号上进行过微信登录授权。 这样可让其他同主体的App、公众号、小程序的开发者快速获得已有用户的数据。 不依赖登录的用户信息获取某些工具类的轻量小程序不需要登录行为，但是也想获取用户信息，那么就可以在 [代码]wx.getUserInfo[代码] 的时候加一个参数 [代码]withCredentials: false[代码] 直接获取到用户信息，可以少一次网络请求。 这样可以在不给用户弹窗授权的情况下直接展示用户的信息。 最佳实践 1.调用 [代码]wx.login[代码] 获取 [代码]code[代码]，然后从微信后端换取到 [代码]session_key[代码]，用于解密 [代码]getUserInfo[代码]返回的敏感数据。 2.使用 [代码]wx.getSetting[代码] 获取用户的授权情况  1) 如果用户已经授权，直接调用 API [代码]wx.getUserInfo[代码] 获取用户最新的信息；  2) 用户未授权，在界面中显示一个按钮提示用户登入，当用户点击并授权后就获取到用户的最新信息。 3.获取到用户数据后可以进行展示或者发送给自己的后端。 One More Thing 除了获取用户方案介绍之外，再聊一聊很多初次接触微信小程序的开发者所不容易理解的一些概念： 1.关于OpenId和UnionId [代码]OpenId[代码] 是一个用户对于一个小程序／公众号的标识，开发者可以通过这个标识识别出用户。 [代码]UnionId[代码] 是一个用户对于同主体微信小程序／公众号／APP的标识，开发者需要在微信开放平台下绑定相同账号的主体。开发者可通过[代码]UnionId[代码]，实现多个小程序、公众号、甚至APP 之间的数据互通了。 同一个用户的这两个 ID 对于同一个小程序来说是永久不变的，就算用户删了小程序，下次用户进入小程序，开发者依旧可以通过后台的记录标识出来。 2.关于 getUserInfo 和 login 很多开发者会把 [代码]login[代码] 和 [代码]getUserInfo[代码] 捆绑调用当成登录使用，其实 [代码]login[代码] 已经可以完成登录，[代码]getUserInfo[代码] 只是获取额外的用户信息。 在 [代码]login[代码] 获取到 [代码]code[代码] 后，会发送到开发者后端，开发者后端通过接口去微信后端换取到 [代码]openid[代码] 和[代码]sessionKey[代码]（现在会将 [代码]unionid[代码] 也一并返回）后，把自定义登录态 [代码]3rd_session[代码]返回给前端，就已经完成登录行为了。而 [代码]login[代码] 行为是静默，不必授权的，用户不会察觉。 [代码]getUserInfo[代码] 只是为了提供更优质的服务而存在，比如展示头像昵称，判断性别，开发者可通过 [代码]unionId[代码] 和其他公众号上已有的用户画像结合来提供历史数据。因此开发者不必在用户刚刚进入小程序的时候就强制要求授权。 可以在官方的文档中看到 [代码]login[代码] 的最佳实践： [图片] Q & A Q1: 为什么 login 的时候不直接返回 openid，而是要用这么复杂的方式来经过后台好几层处理之后才能拿到？ A: 为了防止坏人在网络链路上做手脚，所以小程序端请求开发者服务器的的请求都需要二次验证才是可信的。因为我们采取了小程序端只给 [代码]code[代码] ，由服务器端拿着 [代码]code[代码] 和 [代码]AppSecrect[代码] 去微信服务器请求的方式，才会给到开发者对应的[代码]openId[代码] 和用于加解密的 [代码]session_key。[代码] Q2: 既然用户的[代码]openId[代码] 是永远不变的，那么开发者可以使用[代码]openId[代码] 作为用户的登录态么？ A: 不行，这是非常危险的行为。因为 [代码]openId[代码] 是不变的，如果有坏人拿着别人的 [代码]openId[代码] 来进行请求，那么就会出现冒充的情况。所以我们建议开发者可以自己在后台生成一个拥有有效期的 [代码]第三方session[代码] 来做登录态，用户每隔一段时间都需要进行更新以保障数据的安全性。 Q3: 是不是用户每次打开小程序都需要重新[代码]login[代码]？ A: 不必，可以将登录态存入[代码]storage[代码]中，用户再次登录就可以拿[代码]storage[代码] 里的登录态做正常的业务请求，只有当登录态过期了之后才需要重新[代码]login[代码] 。这样子做一则可以减少用户等待时间，二则可以减少网络带宽。 目前微信的[代码]session_key[代码] 有效期是三天，所以建议开发者设置的登录态有效期要小于这个值。

前言 由于一些开发者的滥用，为了优化用户体验，微信官方在获取用户信息上，提供了新的API「wx.getUserProfile」，接下来作者将带你解读官方公告（传送门： 小程序登录、用户信息相关接口调整说明），进一步提升“面向公告编程”能力。 常见问题 1、线上版本是不是一定要接入新的 API 才能正常使用？ 并不是哦，如果你的小程序是在 2021 年 4 月 13 日后发布的才需要接入，此前发布的线上版本仍不受影响。 2、wx.getUserProfile 从 2.10.4 基础库开始支持，那么 2.10.4 以下基础库不就使用不了这个 API 了吗？ 并不是哦，2.10.4 以下基础库仍然可以通过调用原有 API「wx.getUserInfo」获取用户信息及进行解密。 3、为什么开发版和体验版调用 wx.getUserInfo 都不返回用户信息了？ wx.getUserInfo 开发版和体验版已对齐匿名表现(返回如下图结果)，因此开发者可在 2021 年 4 月 13 日前在开发版或者体验版中，适配新的登录授权流程。 [图片] 4、wx.getSetting 无法获取用户信息的授权(即 scope.userInfo )？ 从 2021 年 4 月 13 日开始，无论是通过 wx.authorize 请求授权还是 wx.getSetting 获取授权状态，都将直接返回 true。【PS：由于 wx.getUserProfile 每次调用时都需要用户弹窗授权，因此将无法获取用户授权状态】 [图片] 5、wx.getUserProfile 为什么只能获取到 userInfo 信息，却获取不到 rawData、signature、encryptedData、iv 等信息呢？ 据悉，这几天会灰度 2.10.4 ~ 2.16.0 之间支持获取 rawData、signature、encryptedData、iv 等加密信息，具体以官方通知 / 文档为准 新的 API 对基础库有一定的要求，除了参数 userInfo 的值需要 2.10.4 及以上基础库支持获取之外，其它参数也需要 2.16.0 及以上基础库才支持获取。【PS：目前基础库在 2.10.4 ~ 2.16.0 之间将无法获取 rawData、signature、encryptedData、iv 等信息，具体以官方通知为准】 [图片] 6、PC 端微信暂不支持新的 API「wx.getUserProfile」应该怎么处理？ 可以通过以下方式兼容。【PS：暂不推荐使用 wx.canIUse(“getUserProfile”) 做兼容判断，后续可使用该方式进行判断】 [代码]if (wx.getUserProfile) { console.log("支持 wx.getUserProfile") } else { console.log("不支持 wx.getUserProfile") } [代码] 7、开发者工具或真机提示 wx.getUserProfile is not a function 错误信息，应该怎么处理？ ① 确认开发者工具为 1.05.2103022 及以上版本，并且调试基础库为 2.10.4 及以上。 ② 确认手机微信为 7.0.9 以上版本，且基础库为 2.10.4 及以上。 ③ 如果工具内基础库已设置为 2.10.4 及以上，仍报同样的错误信息，可尝试调高工具基础库直至支持此 API 【PS：一切以真机为准！】 8、wx.getUserProfile 获取 encryptedData 及 iv 参数后进行解密，无法获取到 openid 等信息？ 原来调用 wx.getUserInfo 后进行解密可以获取到 openId 等信息如图 1 所示，但是新的 wx.getUserProfile 将无法直接获取到此类用户标识，返回的信息如图 2 所示。 [图片] 9、解密用户信息将不会返回 openId 及 unionId 这类信息，应该怎么解决处理？ 新的登录流程有变化！开发者通过 wx.login 获取到用户登录凭证 (code)，调用微信登录接口（auth.code2Session）将直接返回 openId、unionId（请先确认已在开放平台绑定该小程序，绑定流程：登录 微信开放平台 — 管理中心 — 小程序 — 绑定小程序） 10、wx.getUserProfile 跟 wx.login 无法同时调用，报 getUserProfile:fail can only be invoked by user TAP gesture 错误信息？ 请勿在 wx.login 的 success 回调中调用 wx.getUserProfile。 解决方式： 先使用 [代码]checkSession[代码] 进行登录态检查；提前调用 [代码]wx.login[代码] 再调用 [代码]wx.getUserProfile[代码]，完成授权登录流程。 先拖更 据悉：wx.getUserProfile 计划从基础库版本 2.6.6 开始支持 有疑问欢迎在下方留言或者发社区私信

客服消息中”扫描二维码“能激活客服消息，指的是什么场景下的二维码？

已经关注公众号的用户扫描二维码进入公众号后，能不能直接给ta发送48小时客服消息？

https://developers.weixin.qq.com/doc/offiaccount/Message_Management/Service_Center_messages.html 公司的项目是web应用，想使用微信公众号卡券功能，我们在微信后台制作卡券后，然后在web端，当用户报名某个活动的时候，想通过微信客服消息的方式发放活动的微信卡券。文档里关于微信公众号活跃用户有要求必须是48小时内的活跃用户，另外给出了5个触发机制，分别是： 用户发送信息点击自定义菜单（仅有点击推事件、扫码推事件、扫码推事件且弹出“消息接收中”提示框这3种菜单类型是会触发客服接口的）关注公众号扫描二维码支付成功问了好几次腾讯客服，告诉的都是第4点就是扫微信公众号二维码，关注微信公众号，那么我想搞明白第3点和第4点有什么区别是？？？ 到底第4点扫描二维码是扫什么二维码可以使用户成为48小时活跃用户。

服务号模板消息能力的设计初衷，旨在帮助开发者实现及时通知，但存在一些问题，如： 1. 部分开发者在用户无预期的情况下，发送与用户无关的信息，对用户造成了骚扰。 2. 模板消息是用户触发后的通知消息，不支持营销类消息，不能满足部分业务需求。 为提升微信用户体验，我们开始灰度测试服务号订阅通知功能。 能力说明 开发者可在服务号图文消息、网页等场景设置订阅功能，用户自主订阅后，开发者可按需求下发一条对应的订阅通知。 [图片] 用户可在图文订阅通知 [图片] 用户可在网页订阅通知 灰度测试计划 服务号订阅通知功能即日上线，已认证的境内主体服务号可前往 MP 后台开通使用，详见说明。 1. 服务号订阅通知灰度测试期自2021年1月27日0:00至4月30日24:00，期间服务号模板消息可正常使用；灰度测试期结束后服务号订阅通知的策略将另行公布，届时以官方信息为准； 2. 开发者使用订阅通知功能时，需遵循运营规范，不可用奖励或其它形式强制用户订阅，不可下发与用户预期不符或违反国家法律法规的内容。具体可参考文档：《微信公众平台运营规范》 微信团队 2021年1月27日

一、能力背景 近年来，国家在医疗挂号、APP注册、快递收寄、客运、运营商等多领域规定，需要用户实名才可办理业务，预计后续也会有越来越多的此类法规。因此，微信参照公安部“互联网+”可信身份认证服务平台标准，依托腾讯公司及微信的生物识别技术，建立微信“实名实人信息校验能力” ，即通过人脸识别+权威源比对，校验用户实名信息和本人操作（简称微信人脸核身）。 目前接口限定主体及行业类目开放公测，提供给资质符合要求的业务方，在合适的业务场景内使用。目前仅支持持二代身份证的大陆居民。 由于人脸核身功能涉及到用户的敏感、隐私信息，因此调用此接口的小程序，需要满足一定的条件。即：小程序的主体以及类目，需要在限定的类目范围内，且与小程序的业务场景一致。开展的业务也需要是国家相关法规、政策规定的需要“实名办理”的相关业务（其他未在范围内的业务，则暂不支持）。 以下为接口接入及开发的详细内容。如开发中遇到任何疑问，可以点击此处通过社区反馈，将有工作人员跟进回复。 文档第四部分【再次获取核验结果api】，有助于提高业务方安全性，请务必接入！ 现阶段微信人脸核验能力，针对小程序，开放的主体类目范围包含： 小程序一级类目 小程序二级类目 小程序三级类目 使用人脸核验接口所需资质 物流服务 收件/派件 / 《快递业务经营许可证》 物流服务 货物运输 / 《道路运输经营许可证》（经营范围需含网络货运） 教育 学历教育（学校） / （2选1）：1、公立学校：由教育行政部门出具的审批设立证明 或 《事业单位法人证书》；2、私立学校：《民办学校办学许可证》与《民办非企业单位登记证书》 医疗 公立医疗机构 / 《医疗机构执业许可证》与《事业单位法人证书》 医疗 互联网医院 / 仅支持公立医疗机构互联网医院（2选1）：1、卫生健康部门的《设置医疗机构批准书》；2、 《医疗机构执业许可证》（范围均需含“互联网诊疗”或名称含“互联网医院”等相关内容 医疗服务 三级私立医疗机构 / 仅支持三级以上私立医疗机构，提供《医疗机构执业许可证》、《营业执照》及《医院等级证书》 政务民生 所有二级类目 / 仅支持政府/事业单位，提供《组织机构代码证》或《统一社会信用代码证》。 金融业 银行 / （2选1）：1、《金融许可证》； 2、《金融机构许可证》。 金融业 信托 / （2选1）：1、《金融许可证》； 2、《金融机构许可证》。 金融业 公募基金 / （4选1）：1、《经营证券期货业务许可证》且业务范围必须包含“基金”；2、《基金托管业务许可证》； 3、《基金销售业务资格证书》；4、《基金管理资格证书》。 金融业 证券/期货 / 《经营证券期货业务许可证》 金融业 保险 / （8选1）：1、《保险公司法人许可证》；2、《经营保险业务许可证》；3、《保险营销服务许可证》；4、《保险中介许可证》；5、《经营保险经纪业务许可证》；6、《经营保险公估业务许可证》或《经营保险公估业务备案》；7、《经营保险资产管理业务许可证》 ；8、《保险兼业代理业务许可证》。 金融业 消费金融 / 银监会核准开业的审批文件与《金融许可证》与《营业执照》 金融业 汽车金融/金融租赁 / 仅支持汽车金融/金融租赁主体，同时提供：1、《营业执照》（公司名称包含“汽车金融” /“金融租赁”；营业范围包含“汽车金融”/“金融租赁”业务）；2、《金融许可证》或银保监会及其派出机构颁发的开业核准批复文件。 交通服务 网约车 快车/专车/其他网约车 （自营性网约车）提供《网络预约出租汽车经营许可证》。（网约车平台）提供与网约车公司的合作协议以及合作网约车公司的《网络预约出租汽车经营许可证》。 交通服务 航空 / （航司）提供《公共航空运输企业经营许可证》。（机场）提供《民用机场使用许可证》或《运输机场使用许可证》。 交通服务 公交/地铁 / 提供公交/地铁/交通卡公司《营业执照》 交通服务 水运 / （船企）提供《水路运输许可证》。（港口）提供《港口经营许可证》 交通服务 骑车 / 仅支持共享单车，提供共享单车公司《营业执照》 交通服务 火车/高铁/动车 / 仅支持铁路局/公司官方，提供铁路局/公司《营业执照》 交通服务 长途汽车 / （2选1）：1、《道路运输经营许可证》（经营范围需含客运）；2、官方指定联网售票平台（授权或协议或公开可查询文件）。 交通服务 租车 / 运营公司提供《备案证明》与对应公司《营业执照》，且营业执照中包含汽车租赁业务 交通服务 高速服务 / 仅支持ETC发行业务，（2选1）：1、事业单位主体，需提供《事业单位法人证书》；2、官方指定的发行单位（一发单位），需提供“官方授权或协议，或公开可查询的文件”； 生活服务 生活缴费 / （供电类）提供《电力业务许可证》与《营业执照》，且《营业执照》且经营范围含供电。（燃气类）提供《燃气经营许可证》与《营业执照》，且《营业执照》且经营范围含供气。（供水类）提供《卫生许可证》与《营业执照》。（供热类）提供《供热经营许可证》与《营业执照》，且《营业执照》且经营范围含供热。 IT科技 基础电信运营商 / （2选1）：1、基础电信运营商：提供《基础电信业务经营许可证》；2、运营商分/子公司：提供营业执照（含相关业务范围）。 IT科技 转售移动通信 / 仅支持虚拟运营商，提供《增值电信业务许可证》（业务种类需含通过转售方式提供移动通信业务） 旅游服务 住宿服务 / 仅支持酒店，提供《酒店业特种行业经营许可证》 商业服务 公证 / 仅支持公证处，提供《公证处执业许可证》或《事业单位法人证书》 社交 直播 / （2选1）：1、《信息网络传播视听节目许可证》；2、《网络文化经营许可证》(经营范围含网络表演）。 如对以上类目或资质有疑问，可点击参考小程序“非个人主体开放的服务类目”，详细了解小程序开放的服务类目及对应资质。 二、准备接入 （请在小程序发布后，再提交人脸核身接口申请） 满足第一节中描述的类目和主体的小程序，可申请微信人脸核验接口。目前微信人脸核身接口已改为线上自助申请方式，需按照如下图例指引，进行接口申请： 第一步：请通过mp.weixin.qq.com登录小程序账号在后台“功能-人脸核身”的路径，点击开通按钮—— [图片] 第二步：仔细查阅《人脸识别身份信息验证服务条款》后，点击“同意并下一步”—— [图片] 第三步：请正确填写服务信息，并上传该小程序类目下所要求的资质—— [图片] 第四步：请按照业务实际需求填写使用人脸接口的场景和用途—— [图片] 第五步：请完善测试信息和联系人—— [图片] 第六步：提交后请耐心等待1-3个工作日的审核期，审核结果将以站内信通知—— 如申请期间遇到问题，可联系腾讯工作邮箱 wx_city@tencent.com，将会有相关工作人员进一步指引。 三、接口文档： (一)接口描述 名称: wx.startFacialRecognitionVerify(OBJECT) 功能：请求进行基于生物识别的人脸核身 验证方式：在线验证 兼容版本： 一闪：android 微信7.0.22以上版本, iOS 微信7.0.18以上版本 建议在微信官网升级至最新版本 (二)参数说明 1、OBJECT参数说明： 参数 类型 必填 说明 name String 是 姓名 idCardNumber String 是 身份证号码 success Function 否 调用成功回调 fail Function 否 调用失败回调 complete Function 是 调用完成回调（成功或失败都会回调） 2、CALLBACK返回参数 参数 类型 说明 errMsg String 错误信息 errCode Number 错误码 verifyResult String 本次认证结果凭据，第三方可以选择根据这个凭据获取相关信息 注 1：传递用户姓名和身份证有两种方式 业务方没有用户实名信息，用户需要在前端填写身份证和姓名，那么前端直接通过jsapi 调用传递 name 和 idCardNumber。 业务方已经有用户实名信息，后台通过微信提供的 api（详情见文档后面“上传姓名身份证后台 api”）上传用户身份证姓名和身份证，api 返回 user_id_key 作为凭证传给前端，前端再调用 jsapi，用户姓名、身份证信息不需要经过前端，参数只需要传递 userIdKey。Tips：使用该功能需要小程序基础库版本号>=1.9.3。 3、回调结果说明 回调结果请参考以下释义： [图片] [图片] [图片] 4、示例代码 [图片] [图片] (三)上传用户姓名身份证的后台api 1、API说明 1.1说明 业务方上传用户姓名和身份证，获取用户凭证，把凭证给到前端通过 jsapi 调用。 Tips ：使用该功能需要小程序基础库版本号>=1.9.3。 1.2请求URL https://api.weixin.qq.com/cityservice/face/identify/getuseridkey?access_token={ac cess_token} 1.3请求方式 POST 2、请求数据格式 [代码]Json { "name" : “张三”, "id_card_number" : "452122xxxxxxx43215" } [代码] 请求示例 [代码]#!/bin/bash TOKEN='xxxxxxxxxxxx' URL='https://api.weixin.qq.com/cityservice/face/identify/getuseridkey' JSON='{ "name": "张三", "id_card_number": "452344xxxxxxxxxxxxx234"}' curl "${URL}?access_token=${TOKEN}" -d "${JSON}" [代码] 参数说明 json 字段 中文显示 是否必传 name 姓名 是 id_card_number 身份证号码 是 out_seq_no 业务方唯一流水号 否 3、返回数据 参数 类 型 说明 errcode int 错误码 errmsg string 错误信息 user_id_key string 用于后台交互表示用户姓名、身份证的凭证 expires_in uint32 user_id_key 有效期，过期需重新获取 [代码]{ "errcode" : 0, "errmsg" : "ok", "user_id_key" : "id_key_xxxx", "expires_in": 3600 } [代码] 4、后台消息推送 如果业务方传入out_seq_no，核身完成后会通过消息推送回调给业务方的服务器，如果回调业务方失败，会在5s尽力推送，超过5s不再推送。 参数说明 参数 类 型 说明 ToUserName string 小程序原始ID FromUserName string 事件消息openid CreateTime uint32 消息推送时间 MsgType string 消息类型 Event string 事件类型 openid string 核身用户的openid out_seq_no string 业务方唯一流水号 verify_result string 核身返回的加密key（凭据） 返回示例 [代码]{ "ToUserName": "gh_81fxxxxxxxx", "FromUserName": "oRRn15NUibBxxxxxxxxx", "CreateTime": 1703657835, "MsgType": "event", "Event": "face_identify", "openid": "oRRn15NUibBxxxxxxxxx", "out_seq_no": "test1234", "verify_result": "XXIzTtMqCxwOaawoE91-VNGAC3v1j9MP-5fZJxv0fYT4aGezzvYlUb-n6RWQa7XeJpQo0teKj8mGE4ZcRe1JI3GqzADBYORBu613rKjKAFfEXTXw_bu1bs7MnmPOpguS" } [代码] 四、再次获取核验结果api 此接口是前端完成人脸核身后，基于前端返回的凭据，通过后台api再次进行核验结果和身份信息的校验，有助于提高安全性，请务必接入！ 前端获取结果不可信，存在被篡改的风险，为了保障请求结果安全性，请务必对identify_ret、id_card_number_md5、name_utf8_md5字段进行校验！ (一)API说明 1、说明 人脸核身之后，开发者可以根据jsapi返回的verify_result向后台拉取当次认证的结果信息。 2、请求URL https://api.weixin.qq.com/cityservice/face/identify/getinfo?access_token={access_token} 3、请求方式 POST 4、请求格式 json (二)请求数据说明 1、请求 参数 类型 是否必填 描述 verify_result String 是 jsapi返回的加密key（凭据） 2、数据返回 HTTP 头如下 Date: Mon, 06 Feb 2017 08:12:58 GMT Content-Type: application/json; encoding=utf-8 Content-Length: 85 Connection: close json示例 [代码]{ "errcode" : 0, [代码] [代码]"errmsg" : "ok", "identify_ret" : 0, "identify_time" : 1486350357 "validate_data": "8593" [代码] [图片] (三)返回参数说明 1、返回参数 注：errcode和identify_ret同时为0，代表本次认证成功。 参数 类型 描述 errcode int 错误码, 0表示本次api调用成功 errmsg string 本次api调用的错误信息 identify_ret int 人脸核身最终认证结果 identify_time uint32 认证时间 validate_data string 用户读的数字（如是读数字） openid string 用户openid user_id_key string 用于后台交互表示用户姓名、身份证的凭证 finish_time uint32 认证结束时间 id_card_number_md5 string 身份证号的md5（最后一位X为大写） name_utf8_md5 string 姓名MD5 2、错误码对应信息 errcode 备注 84001 非法identity_id 84002 用户信息过期 84003 用户信息不存在 五、小程序辅助接口：检查设备是否支持人脸检测 1、接口名称 接 口 ：wx.checkIsSupportFacialRecognition(OBJECT) 功能：检查设备是否支持人脸检测 2、接口说明和使用 小程序调用该接口，可以检测当前手机设备是否具备支持人脸检测的能力，可与以上接口分开使用，为了用户体验，建议调用后对手机设备不支持的用户做对应功能处理。 3、接口说明和使用 01 OBJECT 参数说明： 参数 类型 是否必填 描述 success Function 否 调用成功回调 fail Function 否 调用失败回调 complete Function 是 调用完成回调（成功或失败都会回调） checkAliveType Number 否 人脸核验的交互方式，默认读数字（见表 2） 表 2：checkAliveType 的值和对应的解释： 参数 解释 2 先检查是否可以屏幕闪烁，不可以则自动为读数字 02 CALLBACK 返回参数 参数 类型 说明 errMsg Boolean 错误信息 errCode Number 错误码 03 回调结果说明 回调类型 ErrCode 说明 sucess 0 支持人脸采集 fail 10001 不支持人脸采集：设备没有前置摄像头 fail 10002 不支持人脸采集：没有下载到必要模型 fail 10003 不支持人脸采集：后台控制不支持 回调结果说明仅对Android生效，iOS不返回errcode。 04 示例代码 [图片] 六、安全性说明 为保障业务可用性以及安全性，请详细研读微信人脸核身接口相关基础说明及安全说明文档：https://docs.qq.com/doc/DTFB0YWFIdGV6amly 备注：如开发中遇到任何疑问，可以点击此处通过社区反馈，将有工作人员跟进回复。 七、案例展示及补充说明 安徽医科大学第二附属医院，微信人脸核验登录： 安徽医科大学第二附属医院，是三级甲等综合医院。其小程序为用户提供挂号、门诊费用、住院费用、检查报告、体检等医疗服务，同时也提供停车、餐饮等便民服务，是医疗小程序中完整的案例。 小程序使用了微信人脸核验能力作为登录的核验。满足医院管理要求，也满足国家对于实名就医的管理规则。 案例实现的截图效果如下： [图片] [图片] 针对近期少数小程序方面反馈的两类问题，也在本课程进行补充说明。 1、本接口的开放范围，即：可支持的主体类目，是否可以扩大？ 说明：基于本接口整体使用范围的评估、相关法规的参考、监管策略的理解执行等，暂时未立刻进行扩大开放范围的工作。 但我们会持续基于不同行业的法规、政策及监管要求等，逐一进行研究考量，以便确认如何扩大开放范围。 2、小程序如果涉及用户本人的生物特征采集，（如本人人脸照片、人脸视频），或涉及采集用户本人生物特征信息并开展人脸核验功能，则存在被驳回的情况？ 说明：近两年“人脸识别”技术在社会上掀起了热潮。人脸识别虽然作为摆脱“中间媒介”或“承载载体”的一种直接技术手段，解决了部分政务、交通、医疗、零售等证明“操作者是本人”的问题，但也因此，引入了新的更大的安全风险。 一是，虚假安全风险。 身份认证领域的安全三因素包括“我知道什么”、“我拥有什么”、“我的特征是什么”，通用的安全做法，是要双因素认证（2FA），人脸识别技术如仅凭“我的特征是什么”这一个因素，则容易被攻破或利用。表象给用户以安全的感觉，但实际并不能达到安全效果。 二是，信息泄漏的风险。 越来越多的组织或个人，在并非必需用户敏感信息、生物特征的情况下，采集并存储此类信息。在信息加密、传输、存储过程中，容易暴漏更多的网络节点，使得此类信息有更大的风险被网络黑客拦截、窃听、窃取，或直接被脱库。 三是，消除风险的难度大。 以往基于“中间媒介”或“承载载体”的方式，如出现丢失、被冒用、恶意盗用等风险，可以通过挂失、更换、使用新载体或新媒介等方式，快速排除一定的风险。C端主动，B端主动，都能解决一部分问题。但人脸识别做为更直接的方式，一旦出现冒用、盗用，受害者将面临更大的财产及人生安全风险，且C端用户更多时候无法主动消除风险。 基于以上问题风险，加之国家出台《网络安全法》、《用户隐私保护条例》等法律法规标准，网信办、公安部、工信部及市场监管总局等四部委发起的app获取隐私整治，结合平台安全、用户敏感隐私信息保护要求及监管，针对部分暂无相关法规或要求，需要采集或生物认证方式进行身份核验的，或以“追热点”或“尝鲜”为目的，采集用户生物特征或进行身份核验的，进行严格审核，必要时不予以支持。

[图片] 项目是为医院做的来院人员流行病学史调查问卷，需要收集用户姓名、手机号码、身份证号码和居住地 3.4.1 在收集和使用用户任何数据时，必须明确告知用户该数据的用途，确保经过用户明确同意和授权，并应在用户同意和授权的范围内进行合理使用。在用户注销帐号后应相应删除相关数据。数据包括但不限于获取地理位置、用户通讯录、用户手机号码等。 在第一次不通过后修改为： [图片] 并在版本描述中详细说明了使用场景和用途 [图片] 再次审核不通过，需要修改收集的信息内容吗？

微信小商店优势何在？ 其实刚才说的三个点【0元入驻】、【快速开店】、【微信直播】，就是最大的优势了，当然毕竟这是官方出品的东西，不会因为各种营销操作被封之类的。 尤其是对于个人微商来说，不愿意花钱或买不起第三方小程序的来说，确实是好东西，当然基础功能目前还是比较鸡肋的，这个先不说。另外最核心的就是可以接入微信直播，这应该是蛮吸引人的，跟douyin小店其实是一个性质。 这里说句实在话，结合目前支持的店铺功能来说，微信小商店只是适合那些买不起小程序个体兼职微商，毕竟功能上太过鸡肋，当然了，免费的有，总比没有强。 目前基本上只有【产品管理】功能和【订单】功能，其余的功能正在开发中，也就是能满足基础的买与卖，说到花样基本上没有。 a.不支持无快递销售和到店自取：客户下单后，需要确定发货就得需要快递单号，凡是没有快递单号的，就无法确认订单，也就意味着销售额是到不了账的。目前社区内的反馈就是，正在开发，只能继续等。也就是说做无快递生意的，现在还没法用。 b.企业的营销功能暂无：像我们做社群营销和私域流量的，一定会用到的功能：优惠券/会员/分销/代理推广员/红包拉新等等，暂时还没有，包括常见的营销花样：拼团/助力/砍价/秒杀等也没有踪影。 c.这些功能未来会不会有：快递的问题肯定会解决，但其他的功能真的很难说，毕竟微信是不喜欢微商的，尽管通过小商店来无限的规范微商，但微信应该不会越自己的界，在去年10月28号的微信新政中开始封杀带有引诱性质的拼团/助力链接，那就意味着，微信基本上是不会开发过多的营销花样。所以期待这块的，就别多想了。

详细使用指引可点击这里 导购分销——使用指引 关于导购管理员的功能详尽说明 导购管理员 -- 指引与常见问题 有疑问可在本页面留言咨询  导购分销是什么 导购分销是一个让人可以帮你一起卖货的销售激励能力。 通过添加企业员工、门店导购、渠道经销商等小商店关联角色为导购分销员，设置商品的销售提成来激励分销员线上销售，迅速扩张线上销售额。 [图片] 导购分销能帮助你的小商店做什么 核心效益 利用熟人社交，获取一传十、十传百的流量输入微信号即可添加一个导购分销员，每个导购分销员都有独立的移动端管理工作台，分销员可以查看可推广的商品，并直接分享给自己的微信好友，好友购买后，将呈现对应的提成业绩给该分销员。 同时，小商店店主可添加不同的分销员管理员，交由分销员管理员去添加、管理不同群组的分销员，每个群组内的分销员的总业绩均可分别汇总查看。 激励员工，刺激销售积极性，增加线上销售额方便有员工的企业，实现全员皆销售的数字化管理，无论是门店店员还是其他员工，均可以通过微信号，添加为小商店的导购分销员； 同时支持通过不同梯度等级提成模版的设置，激励员工通过提升销售业绩获取更高的提成比例。添加为导购销售员的员工与管理者，均可实时看到当前的业绩，与应该结算的提成金额，管理者可以按照设定时间导出每个导购分销员的业绩 赋能现有渠道商，数字化管理与对账添加渠道合作伙伴的微信号为导购分销员、或者导购分销管理员，为不同的合作伙伴设置不同的等级提成模版，渠道销售伙伴的线上销售额将会实时呈现给你与你的合作伙伴，方便进行数字化管理与对账。 导购分销的主要功能简介 你是店主或者店铺运营者 谁可以成为你店里的导购分销员？ 人数有没有限制？ 导购分销员的添加与管理店长可以添加导购管理员，导购管理员可以添加导购分销员。 * 店长在PC后台，店铺管理->成员管理，可添加导购管理员，仅有导购管理员权限的店铺成员，将仅能管理导购，而看不到店铺后台其他信息。 可设置经销商、门店店长、代理等合作伙伴为导购管理员。 [图片] 导购管理员，添加为小商店的分销员（通过微信号）。 支持通过excel文件批量添加。 [图片] 单个小商店，最多可添加N名导购管理员：N = 200个 单个小商店，单个导购管理员，最多可添加N名导购分销：N = 500名 （可以删除，删除后的不在这个域里面） 单个微信用户最多可以绑定成为N个小商店的导购分销：N = 50个 导购分销员需要做什么，提成才会作效？与分销员的绑定有效期是可以调整的吗？ 分销员的客户关系设置 导购分销员需要通过分享商品给用户，引导用户到你的小商店购买，用户通过导购分销员分享的海报进入小商店直接下单，该笔订单将按照分佣比例在结算时间结算给该分销员。（目前需要商家按照数额线下结算给分销员） 在客户关系有效期内，客户自行搜索，或者从最近访问的小程序中访问了该小商店，购买了推广商品，也将结算给最后触达（用户通过分享进入小商店）的导购分销员。 商家可以自行按需选择分销员与客户的有效期。 [图片] 什么时候会将提成结算给分销员？ 业绩计算与管理 商家可以在添加导购分销员的设置， 按照需要自行选择结算给导购分销员的时间。 [图片] 目前支持两种结算模式 平台自动结算线下手动打款[图片] 商家若配置为自动结算模式，则在配置的结算时间，提成金额将会打款到导购的微信零钱账户。（该导购的微信账户需要实名认证，才可打款成功） [图片] 若本身配置为线下手动结算，后调整为自动结算，则结算方式在调整后的下一笔订单生效，提成将会自动打款至该导购的微信零钱账户。但是调整之前的线下手动结算订单，仍需商家与导购自行结算。  谁可以看到分销员的业绩？ 该导购的管理员以及小商店的超级管理员（店长）可以看到该导购分销员的业绩，比如A1导购分销员属于B导购管理员，A2导购分销员属于C 导购管理员，C只能看到A2业绩，不能看到A1的。方便商家区分不同渠道商、门店，让渠道商与门店自行管理终端分销人员。 仅有超级管理员可以看到下图全局视角（不同导购管理员分别的销售业绩之和）。 [图片] 每个导购管理员（门店/渠道），仅可查看自己管理的导购的业绩。 [图片] 不同商品，如何设置提成比例？ --推广商品管理与提成设置 商家可从小商店中在架的商品中，选择部分商品，加入推广商品库，加入推广商品库的商品。 * 仅店长有权限管理推广商品，导购管理员无权管理推广商品 [图片] 商家可以为商品设置推广提成比例 支持2种模式设置比例—— 1、按照等级比例 该商品的提成比例将由导购分销员所在等级的提成比例决定（也就是2个不同提成模版、不同等级的分销员，卖出一个商品，拿到的提成会不同）。适合需要通过激励形式鼓励销售员卖更多本店商品的商家。 2、按照固定比例 该商品无论谁卖，都是一个比例。适合特殊价格商品。 [图片] 商家设置完推广商品后，导购分销员可登录移动端，查看自己可以推广的商品和对应的提成。 [图片] [图片] 如何能激励分销员卖出更多商品？ --阶梯等级提成 如果一个导购分销员，知道自己再卖出20件后，每件商品的提成比例会由原来的5%，翻倍变成10%，那么按照目前的销售量，到手的提成也会变多，他将更有动力去完成一开始那20件的商品销售。 合理的设置阶梯的等级提成，将有效提升店铺销售量。 支持按照销售金额/销售笔数2种模式去设置分销员的升级衡量标准，比如客单价比较大的商家（家电、数码等），可按照销售笔数去评估导购分销员的等级，设置比如销售20笔，即可晋级的标准。 客单价较小的，比如食品饮料商家，可按照销售金额，去评估，比如总销售1000元，可晋级下一等级。 [图片] 同时，支持商家设置不同的提成模版，给到各个导购管理员，让他们适用于每个门店/渠道商。 比如大的渠道商，给到一个更大的提成比例区间的模版。 店长可以给导购管理员分配提成模版（导购管理员不可新增和修改提成模版） [图片] 每个导购分销员，最终将仅会关联到一个提成模版中的一个等级。 导购管理员添加导购的时候，可以从导购管理员给他分配的提成模版中，选择一个分配给该导购。 [图片] 你的导购分销员 导购分销员怎么分享商品给用户？ --商品推广 已经被添加为导购分销员的个人，将可以搜索「小商店助手」，进入导购分销模块查看管理 [图片][图片] 通过导购分销员的首页，可以进入推广商品模块。 [图片] 这里呈现的商品将是商家在后台设置的推广商品。 分享方式支持  1、 图文分享，复制带参链接 [图片] 2、 复制小程序路径链接（可在公众号或其他小程序配置本页面） [图片] 3、 分享海报 （适合分享到朋友圈，或者制作线下物料） [图片] 4、 直接点击进入小程序，分享该商品页面 （用户可在会话列表中直接点击进入小商店购买，缩短进入小商店路径） 同时，导购分销员也可以点击商品列表中的商品，直接进入小商店的该商品页面，直接分享小商店的页面（这类方式分享也将计算佣金）。 [图片] 4、 导购的视频号视频下方，扩展链接 [图片] 5、 导购的视频号直播间 你的导购在他自己的视频号可挂你的小商店，也可直播卖你店的货，卖货后，推广商品将同样记佣给该导购。 1. 导购进入自己的视频号（需先开通视频号） 2. 进入视频号账号管理 [图片] 3. 设置关联小商店 [图片] 4. 导购选择小商店关联，若该导购有多个小商店，则需选择它所在的企业店进行关联 [图片] 5. 导购开始视频号直播，上架推广商品（仅销售推广商品会记佣） [图片] 针对不同客户，分销员怎么识别出更加有意向下单的客户？ -- 导购分销员员客户管理 导购分销员可以看到已经访问过自己链接的客户，以及部分每个客户的消费行为 [图片]

各位微信开发者： 你们好。 为了更好的帮助小程序商家提高商品销量，微信官方提供的推广工具“小程序联盟”，于2021年3月1日开始公测。 小程序联盟具有“先成交后付费”的特点，商家在管理后台发布商品推广需求和佣金，佣金在推客（推广者）成功完成推广后才会结算。 功能简介与接入标准请参考下方内容。 一、功能简介 小程序联盟分别为商家和推客（推广者）提供了管理后台： 商家可在管理后台设置商品推广佣金，查看推广效果，具体说明请查看《商家端功能说明》；[图片] 2.推客可在管理后台挑选商品，获取推广素材，查看推广效果，提现佣金，具体说明请查看《推客端功能说明》； [图片] 二、接入要求 拥有商品，希望被推广的小程序商家可申请成为小程序联盟商家。没有货源，希望通过分享商品创造价值的推广者，可以申请成为小程序联盟推客。 具体接入条件如下： 1. 商家 满足以下条件之一，即可开通小程序联盟： 已开张的企业/个体工商户的小商店； 已有小程序并完成标准版交易组件接入。 接入指引，请参考《商家接入指引》。 企业/个体工商户为主体的小商店可直接前往PC端后台开通联盟功能。 [图片] 2. 推客： 支持企业/个体工商户主体接入，通过主体认证即可。 暂未向个人开放。 接入指引，请参考《推客接入指引》。

概述欢迎申请成为微信小程序开发服务商：微信小程序开发服务是微信开放平台第三方服务商的一项服务能力。 成为微信小程序开发服务商你可以创建小程序代开发服务并发布到服务平台。 商家可在服务平台小程序开发专区选购你的服务，并通过授权的方式获得你所提供的服务。 为创建SaaS小程序代开发服务你需完成以下步骤：1. 创建第三方平台 2. 登录服务平台 3. 创建小程序开发服务 内容发布并通过审核后，即可通过小程序开发服务专区向用户提供服务。 审核内容将包括：服务商在所选行业的服务能力、服务标题、服务简介、服务头图、服务效果图，服务功能和套餐的完整性，服务价格的合理性。 入驻基本标准（1）已在微信开放平台通过开发者资质认证，成为微信第三方服务商； （2）具备微信小程序开发能力和服务经验 （入驻服务所选行业下，活跃小程序案例不少于5个）； （3）服务商半年内无违规记录； （4）服务商可在对应行业提供完整的小程序行业解决方案 （对应行业所提交的案例展示小程序需具备平台规定的核心场景之一）。 *详细服务上传审核标准 服务创建规则1. 单个服务对应单个行业，如服务商服务多个行业，则需分别上传多个服务； 2. 单个行业对应上传的服务内容需关联该行业解决方案，不得出现无关/其他行业的内容。 接入流程：一、创建第三方平台（如有可跳过该步骤）第三方平台是服务商创建服务并获取授权的基础体系。第三方平台的申请和上线流程参照第三方平台的申请和上线流程。 注：注册第三方流程根据开发模式选择平台型服务商或定制化服务商 平台型服务商注册说明 定制化服务商说明文档 *服务商需通过第三方平台账号与小程序建立授权关系，并满足入驻标准方可上架服务 二、登录服务平台1. 使用第三方平台管理员微信登陆服务平台（该微信号需同时为与第三方企业主体一致的小程序管理员） [图片] 2. 若无企业主页，点击“创建新的企业主页” 若有企业主页，则请查看步骤（三） [图片] 3. 若无可创建的企业主页，进入微信公众平台“创建新的企业小程序”（企业小程序创建流程），创建成功后，再回到服务平台继续创建企业主页。 [图片] 4. 创建企业主页：选择以某个公司为主体的小程序（每个主体只能创建一个企业主页） [图片] [图片] 5. 选择企业主页的类型 [图片] 6. 确认企业主页的主体 [图片] 7. 完善企业资料并提交 [图片] 三、创建小程序开发服务1. 点击右上角头像，进入“我的主页” [图片] 2. 创建服务，选择“小程序开发” [图片] 3. 填写信息并提交 [图片] 4. 提交审核 在“我的主页”点击“提交审核”，审核通过后服务将展示在服务平台 审核需时1-3个工作日，服务商可在「我的主页」服务列表状态栏查看当前审核状态 [图片] 5. 服务上架

微信开放平台绑定网页跳转移动应用的js安全域名是报:开放平台和服务号主体不一致。但是我的开放平台和服务号的主体设置的是一样的

微信第三方平台appid wxc41f1e563803c084，[图片] 请问一下要如何操作？谢谢

注册企业页的时候, 第三方平台AppID 指的是什么? 是这个申请企业主体开发过的小程序的么, 还是啥意思? [图片]

整体流程，分两种情况： 企业有企业小程序：创建企业主页——创建成功——上架服务——完成企业没有企业小程序：创建企业小程序——创建企业主页——创建成功——上架服务——完成1.进入微信服务平台，点击右上角的“登录” 2.微信扫码登录 [图片]   3.若无企业主页，可以点击头像，然后点击切换账号，点击“创建新的企业主页” [图片] 4.若无可创建的企业主页，进入微信公众平台，“创建新的企业小程序”（企业小程序创建流程），创建成功后，再回到服务平台继续创建企业主页。若有可创建的企业主页，则继续第5步，创建新的企业主页；若已有企业主页，则继续 二、上架服务 [图片] 5.选择创建以某个公司为主体的小程序 6.每个主体只能创建一个企业主页。 [图片] 7：选择企业主页的类型 1.如果你是小程序模版开发服务商（第三方平台），可选择平台型服务商，需要有第三方平台App ID； 2.如果你是为其他企业进行小程序定制化开发的服务商（第三方平台），可选择定制化服务商，需要有第三方平台App ID；； 3.如果你是一个普通商户、政府组织或者媒体，做自己的小程序，可选择普通商户/政府组织/媒体。 [图片] 8：确认企业主页的主体 [图片] 9：编辑企业主页的资料 上传企业主页的logo、填写企业名称、介绍等；企业简称，如深圳市腾讯计算机系统有限公司，企业简称填：腾讯。如果没有简称，可直接填公司名称选择自己服务的行业或者所在行业：服务行业最多可选择4个；所在行业最多可选择1个；若选择了平台型服务商/定制化服务商，需要首先在在微信开放平台创建第三方平台（创建第三方平台的流程），获得第三方平台的 AppID，第三方平台的主体需与企业主页的主体一致。 [图片] 10.编辑完成后的示例如下 [图片] 11.右上角点击头像，进入企业主页，选择“开放服务”——“上架服务”； [图片] 12.以定制化开发为例，选择某个服务，点击“上架”； [图片] 13.完善服务信息，点击“提交”； 注意：是否发布这里，选择是，服务被上线后会被其他用户发现，选择否，服务不上线，只自己可见 [图片] 14.提交后，示例如下 [图片] 15.点击右侧“···”，可对服务进行上架、编辑、删除操作 [图片] 附：关于登录和切换企业主页 若创建企业主页后，企业主页的管理员/运营者可以企业的身份登录服务平台 微信扫码登录 [图片] 2.若有多个企业主页，可选择一个登录 [图片] 2.2切换为企业主页帐号 若创建企业主页后，先以个人的身份登录的，可以直接切换为企业的管理员/运营者的身份登录服务平台，代表企业在服务平台进行操作。 点击右上角的头像，选择切换帐号[图片] 2.若有多个企业主页，可以选择其中一个切换 [图片] 3.企业主页运营 创建成功后，你可以进行如下操作： 1. 编辑企业主页的资料，一个月可以有3次修改机会； 2. 可修改管理员； 3. 添加运营人员，最多可添加10个，运营人员可以企业身份登录企业主页，在服务平台进行操作； 4. 添加企业的小程序或者插件案例，小程序和插件案例可各添加3个； 5. 以企业主页在社区所有的回答、分享、评论与回复，将记录在该企业上。 [图片]

？？？？ 咱也不知道为啥。 小额打款有主体，但是微信认证是未认证。 而且第三方授权之后，也是说没有权限。 不得已，又搞了一遍微信认证 [图片]

普通商户和收付通、服务商都有分账功能，我们是电商平台，可以直接走普通商户的分账功能吗？会不会要求整改为收付通？

一、普通分账 1、普通分账，可不可以理解，一个普通商户账号，钱入进来，然后添加分账接收方，进行分账（分账接收方可以是个人，也可以是别的商户账号）？ 省去了服务商分账中，添加特约商户的步骤？ 2、那么分账接收方有没有数量限制？ 二、服务商分账 1、服务商分账，可不可以理解，钱都是入到特约商户的账号，然后服务商发起分账，抽取其中的一部分？ 还是说，钱也可以像普通分账那样，入到服务商的账号中，然后进行分账？（服务商账号两种分账都支持？） 2、服务商模式下的，添加分账方，是不是可以理解为，除服务商和特约商户外，其它的分账接收方？ 3、分账接收方有么有限制？ 4、特约商户有没有数量限制？

最近动态 wx.getUserProFile() 在2.16.0成功回调有iv、encryptedData，具体看这里https://developers.weixin.qq.com/community/develop/doc/000c04d0490118d8a6ebf675a56c00 调整背景 很多开发者在打开小程序时就通过组件方式唤起 getUserInfo 弹窗，如果用户点击拒绝，无法使用小程序，这种做法打断了用户正常使用小程序的流程，同时也不利于小程序获取新用户。详情可以点击官方调整链接(https://developers.weixin.qq.com/community/develop/doc/000cacfa20ce88df04cb468bc52801) 调整前后API功能的对比[图片] [图片] 能力检测 两个前提条件： 1.开发者工具版本不低于 1.05.21030222.基础库版本不低于 2.10.4[图片] 代码片段: https://developers.weixin.qq.com/s/odMs3wmX7Ko3 测试过程 step1: 在开发工具设置清除全部缓存step2: 点击 getUserInfo 按钮，会弹出用户授权，允许后会得到这些信息，见截图[图片] step3: 在终端输入下面代码，也可以获取上面截图数据（今天还不到截止时间，还能获取完整的用户头像和昵称）wx.getUserInfo({ complete: (res) => { console.log(res) } }) step4: 点击 getUserProfile 按钮，会弹出用户授权，允许后会得到这些信息，见截图（只有用户昵称和头像信息）[图片] step5: 通用在终端输入下面代码，获取不到任何信息，符合`若开发者需要获取用户的个人信息（头像、昵称、性别与地区），可以通过wx.getUserProfile接口进行获取，且开发者每次通过该接口获取用户个人信息均需用户确认`wx.getUserProfile({ complete: (res) => { console.log(res) } }) step6: 可以重复点击 getUserInfo 按钮和 getUserProfile 按钮进行测试。功能对比讲解 1.4月13日前未发布的，wx.getUserInfo 能力 wx.getUserInfo(Object object) 会返回 encryptedData、signature、rawData，通过将返回的数据传递给服务器，服务端能解析出用户的身份标识，即 unionId(unionId 获取机制：https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/union-id.html) 【对我们业务来说】 从 wx.getUserInfo 就是要两样东西：unionId和用户信息（头像和昵称）。 但从 2021年2月23日起，可以通过 wx.login 接口获取的登录凭证可直接换取 unionID，可以替代一部分wx.getUserInfo 的功能了。 2.新增 getUserProfile 能力 wx.getUserProfile 能获取到头像和昵称，可以替代 wx.getUserInfo 的另外一部分功能。 3.小结 从这里是不是可以得出，wx.login + wx.getUserProfile 基础可以替代之前的 4月13日前未发布的，wx.getUserInfo 能力。其实不然，如果真是这样的，官方是不是没必要这样搞，咱们接着看。 4.wx.getUserInfo 和 wx.getUserProfile 区别 1.功能上是 wx.getUserInfo  不在返回用户授权的头像昵称，只返回匿名信息，但 wx.getUserProfile 会返回用户授权的头像昵称。2.wx.getUserInfo 授权成功后，当下次调用时，可以直接获取授权成功返回数据，不需要每次都需要用户确认，但 wx.getUserProfile 每次都需要用户确认允许后才能拿到用户信息3.对于业务来说，可以通过 wx.getUserProfile 获取用户信息和昵称后，要存在自己服务器，不能像之前那样每次都通过 wx.getUserInfo 方式获取，否则体验会比较差疑问 1.4月13日后发布的新版本小程序，如果用户未更新到新版本，此时调用 wx.getUserInfo 会不会返回用户授权的头像昵称（如果不确定，业务可能需要兼容处理）2.4月13日后发布的新版本小程序，用户更新到新版本，调用 wx.getUserInfo 返回匿名的头像昵称支持服务器解密吗？ 常见问题汇总 1.wx.canIUse 判断getUserProfile结果是false，可以通过直接判断 wx.getUserProfile 即可，类似问题可以查看官方知识库（https://developers.weixin.qq.com/community/develop/doc/000cac40cf0eb8d3e429647c351c09?_at=1614912876047）

关于 serverless 无服务器运算（Serverless computing），又被称为功能即服务（FaaS），是云计算的一种模型。以平台即服务（PaaS）为基础，无服务器运算提供一个微型的架构，终端客户不需要部署、配置或管理服务器服务，代码运行所需要的服务器服务皆由云端平台来提供。 云开发小程序的能力 云开发是微信团队和腾讯云团队共同研发的一套小程序基础能力，简言之就是：云能力将会成为小程序的基础能力。 小程序云开发目前提供三大基础能力支持： 云函数：在云端运行的代码，微信私有协议天然鉴权，开发者只需编写业务逻辑代码 数据库：一个既可在小程序前端操作，也能在云函数中读写的 JSON 数据库 文件存储：在小程序前端直接上传/下载云端文件，在云开发控制台可视化管理 大家可以去看看小程序的文档，也可以参加下公测申请哈：《小程序·云开发》。 解决了什么 天然鉴权 小程序中，要使用第三方服务器，需要走较多的流程，如图（参考官网）： [图片] 在云开发小程序中，使用云函数则无需考虑长长的授权链路，可专心写业务代码。 零部署，零维护 一个小程序的上线，除了大家看到的小程序，背后还有网关、计算服务、基础设施管理、数据库、文件服务、缓存服务等等。日常开发中，随便找个后台服务架构之类的交互图，都会长这么复杂（图文无关，来自随便谷歌的图片）： [图片] 除去这些服务的部署成本，当然少不了还有它们的维护成本。当然，也可以选择各种第三方服务来组合实现，这里面也会有服务的熟悉、比对等各种烦恼。 小程序云开发提供了较完整的服务器架构，结合腾讯云团队的云函数、数据库和文件存储，都可以是相对可靠的服务。如果业务可以使用小程序云开发完成闭环，就能省去不少的开发部署和维护成本。 服务稳定性 日常开发中，除去业务逻辑，我们还需要完善很多基础能力：日志、监控、告警、数据安全、系统性能。业务增长需要扩容，从前端到后台长链路的定位，数据信息的统计，都是需要手动操心的事情。 小程序云开发提供了数据库和文件存储，可在小程序中直接使用，也可以通过云函数去调用，也可以通过小程序云开发的控制台去管理。同时，小程序云开发配备了一些日志、监控和统计分析的功能： [图片] [图片] 数据存储的安全性、服务的稳定性，都有专业团队来保障，不用自己再操心和踩坑了。 弹性的云函数 或许很多人都不大理解云函数是什么，没关系我也是刚刚才接触。云函数大概是一个可运行的代码管理平台，可用把代码存储到平台上，并提供好环境供代码运行。 自动伸缩大概是云函数最特殊和最好用的一个能力了： 无服务器云函数支持毫秒级别的实时弹性伸缩，完全根据请求量扩容或缩容 动态负载均衡将请求分发至后端近乎无限的函数实例上，完全无需任何手动配置和操作，满足并发量从 0 到成千上万的不同场景 更多的能力可参考腾讯云 SCF。 云开发小程序的云函数，是通过 Node.js 来执行的。目前来说，涉及的依赖和安装包，都需要在本地安装后，再上传部署方可使用。不过开发小哥哥们说了，后续会提供线上安装的功能。 便利的权限控制 在大多数业务中，都会存在权限控制以及身份管理，如管理员、用户、数据创建者。而小程序云开发的数据库和文件存储，提供了以下的权限管理方式： [图片] 万能的 Javascript 大家都说，全栈只是前端里才有的定义。Node.js 其实只是降低了语言的学习成本，但做服务搭建，该学习的还是学习，该掌握的还是得掌握。前端与后台的差距，并不在于语言，即使是一个很简单的系统架构，前端考虑的会欠缺了很多（个人体验，不能代表各种大神）。 云开发小程序，通过提供客户端 API 的方式，封装了很多服务处理和管理维护的过程，使得服务架构对小程序开发者的门槛大大降低。开发者只需要使用 Javascript 一种语言，结合提供的 API，可以完成小程序的开发、服务的业务逻辑编写、数据管理、用户管理，也省去了很多系统安全、服务搭建、性能维护等工作。 还要解决什么 依赖性 目前来说，**小程序云开发的服务，只能局限在小程序里面使用。存储到数据库和文件存储里的数据，暂无法通过其他方式直接获取（当然，你也可以在小程序里通过 http/https POST 出去）。**这意味着我们暂时还不能依赖小程序云开发的存储来做一些运营端、管理页面、自定义的数据分析等。 因为小程序云开发的整个架构设计主要服务于小程序，那么不管是数据库的读写、文件存储的读写，还是云函数的执行触发，都会依赖于小程序。不过，后面应该会有规划将小程序云开发通过鉴权或者授权的机制，让开发者可以从自己的服务器去获取一些信息的吧。 服务局限性 小程序以及云开发与外界（其他服务）的连接，基本上都只能基于 http/https 的方式来进行。相对于我们常用的服务间 TCP 的连接方式，可能会慢一点（其实也可以忽略不计啦）。 同时，目前的云函数会有超时机制（大概5秒），也就是说，一个函数的执行若是超时了，函数调用会被返回，同时该函数的执行也会被中断。普通的 CGI 超时了也会执行完毕，这里会有些不一样。 稳定性保障 新上线的功能，虽然经过了内测，未经过大量的实践，其稳定性和使用性能都待考证。不踩坑是不可能的，这辈子都不会不踩坑的。但相信小程序的开发哥哥们，能保证当前功能的稳定和开发的便捷。毕竟，走得稳才能走得远。 但是新技术或者新功能的上线，都需要大量开发者前仆后继地填坑，才能一起成为首批吃鸡腿的小伙伴呀。（嗯，目前为止踩了一些坑，有机会再跟你们分享吧） 健全的文档 “程序员最讨厌的两件事：1. 别人没有写文档。2. 自己要写文档。” 在新功能上线的初期，文档建设未免都会有些不够完善，当然这也是需要大家多去参与和使用，然后给到反馈和建议，才能做得越来越好。 什么场景适用 个人开发者 无可厚非地，大概是个人开发者最适合使用小程序云开发的模式了。只需要专注于小程序的开发，完全不用考虑后台服务搭建、数据存储、系统安全、服务器运维等工作，只需要使用云开发提供的一条龙服务，就可以开心地完成小程序的开发了。 工具类小程序 由于小程序云开发的功能，目前还只能在小程序里面使用，那对于一些小助手、修图工具、阅读工具等一些工具类小程序，这类需要一些小数据的存储，同时也可以配合 http/https 请求的方式来完成完整的功能。 复杂逻辑的函数计算 “复杂的逻辑放后台。” 不管是以前还是现在，虽然前端的能力范围越来越大，但在业务中依然免不了会遇到一些复杂的逻辑，这时候一般大家都会默认把逻辑放后台计算。因为前端的性能和兼容性，总会因环境和平台的变化而变化，同时单线程的模式也限制了一些大数据的计算分析能力。小程序里也暂时没有类似 Web Worker 的能力（小游戏已经有了，小程序听说在规划中）。 现在，我们可以把这些复杂的逻辑计算放在云函数中来进行，内存分配、计算性能都是云开发来保障，我们甚至可以结合一些开源库，或是云开发提供的 AI 能力，来做一些以前不好做甚至是做不到的功能。 长“缓存”服务 我们经常会使用小程序的缓存来做一些简单的数据缓存，像本地日志、错误信息、告警信息、访问次数等，这些数据可能会被用户手动清除掉（也没有关系），但如果有一个免费又能提供不限时间的存储服务，是否可以将缓存中的数据定期存到小程序云里，然后开发者可以在小程序云开发的控制台里查看这些信息呢？ 向前看 科技在发展，技术一直在变化，作为一个小开发也还是想要拥抱变化和未来的。小程序云开发提供的能力，要改造原有架构来适应或许成本太高，但将其列入未来的可用方案也是不错的方式。 结束语 小程序的开发们都爱低调，但好的东西是要让大家知道的呀就由我来做这个文章的搬运工吧 后面也打算做一系列的小程序相关文章，先立个 Flag。懂的东西不够多，能做的就是写下来和大家一起分享了。 最后，小程序团队和腾讯云团队棒棒哒，此致敬礼！ PS：祝各位开发者写码愉快！成功吃鸡！

一、 从前端技术演进看前端发展野心 前端的技术近几年发展非常迅速，各种框架也如同雨后春笋。 从两个维度去分析前端的技术发展，一个维度是前端复杂度，具体来讲就是前端在解决创建应用复杂度方面做的一些事情；另一个是从广度层面看前端做的事情， 这两个维度构成了一个类似于二维平面的时间事件平面。 [图片] 1. 逐渐降低创建应用复杂度 单看复杂度，前端最开始的阶段只有HTML、JS、CSS，应用虽然是非常简单的，开发起来却是非常复杂的，因此，单单只是DOM操作方面就有大量的DOM操作API。为了降低操作成本，就出现了DOM操作框架，比如jquery。这个阶段类似于从原始的刀耕火种进入石器时代。对dom的操作带来了很大的便利性。尽管如此，真正在构建一个复杂应用的时候，因为业务逻辑和手动操作dom逻辑交织在一起，应用维护变得越来越难。 下一个阶段，引入了MVC分层思想，比如backbone,这能够将逻辑梳理的更加清晰一些。不过，MVC还是需要去关注视图层的。 接着，就出现了mvvm框架，开发者不需要再关注视图层的更新，只需要关注逻辑层、数据层。这一点为构建复杂大型app提供了极大的便利性。mvvm从Angular到现在react、vue的广泛应用，前端在逻辑构建层面发展已经到了一个新的阶段。 在构建大型应用的时候，仅有逻辑层是不行的，还缺乏工程性的思想。因此，出现了打包的模式，帮助我们构建更复杂的应用。这样我们所能做的APP复杂度是一个指数型的增长。 为了进一步提高可构建应用的复杂度、增强前端的性能，assembly技术标准出现，提供了前端字节码的标准，为创建更加复杂的应用打好了坚实的基础。 2. 一直在扩展的前端广度 刚开始只能在浏览器上运行，后来有了node代码，可以让我们的代码扩展到服务器端。紧接着PC端有electron。再到移动端有RN框架，支持我们向移动端进展。 现在出现了小程序，小程序框架能够让前端继续在移动端轻应用做探索。 这里没有讲到的嵌入式开发，这方面也有相应的解决方案。 前端不断扩展广度，把前面的边界不断扩大。 最终前端想一统天下，把前端全栈化。 二、 同时满足技术需求和商业需求的前端全栈 所有的技术在发展时期都有两条线去支撑着它发展，一条线是技术需求，即技术层面的技术创意和技术诉求；另外一条线是商业需求，即技术要满足对应的商业诉求。 [图片] 一个解决方案只有同时满足商业诉求和技术需求，才能蓬勃的发展。如果偏离这两条线，就很难发展起来。举个例子，比如Symbian，有些人有想尝试这个技术诉求，但是因为它已经脱离商业需求的层面，所以这个技术会慢慢被淘汰掉。 那么，如果仅有商业需求又会出现怎样的情况呢？ 比如，2000年的时候对AI有商业上的需求，但是技术需求并满足，当时AI就是一个要被搁置的东西。 前端全栈，是怎样在满足技术需求的同时满足商业需求的呢？ 我们回归到移动端APP的开发实际场景，只有两个层面：一个是UI交互界面的开发，这个是可以被用户感知到的，另外一个是用户感受不到的服务逻辑层面。如果来看现有的开发模式，单单从UI交互界面上来看，就有不同的平台端android、ios、h5，对应的语言有Java、OC、swift、js等几种语言，后端的语言和技术实现是更多的。在现在的模式下，一个小型公司如果需要开发一个完整的APP项目，就需要六种技术！ [图片] 每一种技术如果需要找一个专门的人来做，这就需要6个人。那么反映到公司企业运营上面，人力成本是比较高的，除了人力成本还有同样非常高的沟通成本。从沟通的角度上来看，全栈式开发模式的出现，能够让一个人负责更多的业务开发，降低沟通成本。 由此可见，前端全栈既满足技术需求，也满足商业需求的，所以我相信未来前端全栈一定会蓬勃发展。 三、 打破物理隔离，实现真全栈 再回过头看前端散落的各种技术，在这个发展的过程中，有一个很深的隔离，这个隔离本质上就是物理隔离，比如前端和后端，存在手机和服务器之间的物理隔离。 [图片] **因为各种端是实体端，每个端之间都存在物理隔离。**就比如前端和后端，存在手机和服务器之间的物理隔离。如果能解决这些隔离，就可以把前端的技术做到真正的统一开发模式，才能做到真全栈开发。 [图片] 其实后端的物理隔离，比如每台服务器之间的物理隔离，可以通过云端化，我们把代码上传到云端平台，云端平台会屏蔽机器之间的物理隔离，暴露给开发者的只有一个集群的概念，而不是一台机器一台机器管理部署。云端化之后，后端的物理隔离被消除了。 我们现在的前端代码和服务器之间终存在一个物理隔离，目前的解决方案是通过中间的协议打破物理隔离，比如http协议，但http协议毕竟是中间协议。 而serverless的理念就能完完全全解决掉这层物理隔离，因为代码即服务，serverless能打破这层隔离实现前端的真全栈。 Serverless中的FaaS，函数即服务，我在使用后端服务的时候，不再关心后端的ip地址，后端的域名是什么样的，直接调用函数即可，对前端来说，后端服务是一个函数，函数就是前端的代码的一部分，后端服务和前端完全的融合在一种代码体系里去了，这样后端的服务即是一个函数，至于这个函数是在前端实现，或者是在后端很远的地方实现，开发者都可以不用关心。所以说，severless打破了物理隔离。开发者不再去做任何隔离中间层的事前，我只需要关心函数的实现就可以了，函数也是用我的前端代码来写，所以达到了充分融合的定义。 回过来看具体的实现场景，比如云开发，整个小程序的前后端逻辑都能在一个IDE里面完成，用户其实完全不用担心哪些是服务器的逻辑，他们都去向了哪里，只需要像前端函数一样去理解就可以了。云函数现在也支持了本地调试，就像前端代码一样调试，所以可以做真正的前端全栈技术开发，这对现有的开发模式是一个很大的革新。 四、 小程序云服务的发展优化 那么，在大前端技术发展的这波浪潮里面，小程序云服务又有什么样的发展呢？ 早在2017年初小程序正式发布的时候，第一代腾讯云小程序云服务就已经诞生了，但随着8月份全面向个人开发者开放，我们发现这套支服务还是有一定门槛的。于是就开始着手去做更深度的云服务整合和优化，才有了后来的wafer2 和现在的云开发。 [图片] 早期第一代产品 Wafer 的整个开发部署流程，统计了一下大概需要十几步，对许多中长尾的客户来说并不是那么友好。于是我们开始着手优化。 **通过整个优化，可以简略成四步。**第一步是通过一键的配置购买就能把云开发产品开通起来，第二步是工程师进行小程序的前后台开发，第三步进行代码的预览上传，测试体验完，最后便是发布。经过我们这一两年的努力，小程序开发的流程已经由十几步简化到四步了。目前如果从市面上来看，我们这个产品在用户体验以及流程简化度上，在行业内是较为领先的。 [图片] [图片] [图片] 那么，我们腾讯云团队和微信团队如何一步一步优化我们的产品，将产品的接入门槛降低、流程变简的呢？ [图片] 最初我们看到的是可以将 devops 的部份环节给优化一下，包括代码上传部署。这就催生了后来的Wafer 2，亦即第二代的小程序云服务产品。 另外开通购买步骤也是比较繁琐的。将腾讯云和小程序的账号打通后，可以做到一键授权并且开通环境与服务，并且我们提供了一个免费的开发环境，这样可以让更多开发者在进来发布小程序之前，可以以更低的成本门槛用上云开发。 剩下还可以优化的就只有 SDK 引入和填写配置的环节了。 SDK 其实可以采用内置的方式，毕竟小程序的前端接口也是直接内置到运行环境的 webview里面的。但是配置这块并不太好做了。因为一直以来，小程序前端和后台的开发都是割裂的，因此整个用户的鉴权机制都是交由小程序开发者自己去处理。但为什么小程序与云服务一定是要割裂的呢，为什么不能整合到一起呢？而 Serverless 这种开发模式是前后端紧密结合的最佳粘合剂。 一般而言，请求从小程序侧发起，到云服务的后台逻辑进行鉴权处理，如果鉴权成功再调用微信公开发 API，然后再把数据返回到小程序。 [图片] 但我们稍微将整个请求链路改变一下，小程序侧的请求先通过微信的服务，认证并鉴权成功之后，再到腾讯云这边的 Serverless 服务进行逻辑的处理，处理完毕后再返回到小程序侧。这样，我们把整个配置和鉴权服务都帮用户完成了，这又大大减轻了开发者的负担。 [图片] 通过介绍整个小程序云服务的优化历程，相信大家能感悟到整个产品的理念，就是希望一方面云能力逐步成为小程序开发的基础能力，另一方面也希望尽量减少开发者需要理解的概念。 五、 从前端开发到全栈开发 在云开发模式的推动下，我们开发模式是怎么一步步走到现在的开发模式的？ 在Web刚出现的时候，后台开发本就是大包大揽，后台逻辑完成后，再把模板和数据吐出来到浏览器渲染。当时基本上都是做一些比较简单的Web应用。但是当时没有人会吐槽你的后台工程师只有一个人，怎么都把后台和前端服务都干完了，可能当时的业务逻辑并不是很复杂，前端技术也不是那么的规范化，应用场景不是那么多，所以才出现这样的情况。 可是到后来，随着浏览器逐步发展，JS、CSS、HTML有一个规范委员会帮它每年制定一些新的特性。而且随着业务场景越来越复杂，这种情况下开始提出前后端分离，开始要求后台和前端是分开两个人做事情，前后两端是通过API的请求和返回去做一个数据交互。 再到了2008年的时候，乔老爷子凭一己之力开启了移动端的开发生态。到了2017年张小龙大神也跟微信团队推出了小程序且打造了小程序生态。这个时候很多专家提出了“大前端”的概念，希望只写一份代码，就是编译并完成不同客户端的业务，这些端只需要共享一个后台服务就可以了。 这个时代国外出现了一些跨端方案，比如React Native，国内也涌现了 Taro， Omi 等优秀的跨端方案。这几个时期的前端职能是有明显扩张的。 [图片] 只做了大前端完全满足不了前端的野心，随着Node.js的发展，有一些中台的服务，比如同构渲染和业务接口但逐步转给Node.js 来做。后台的同事开始专注于去写一些后台的调度服务或者优化整个数据的读取性能。这个时期，前端开发者也开始从前端逐步往后台做一个拓展。 [图片] 但大前端的步伐远远不只于此，在很多业务场景里面，前端工程师比较贴近客户，所以他更能够去理解到一些业务逻辑，无论是业务的前台或是后台，交给前端工程师来做是更好的。举个例子，云开发的其中一个客户是唯品会的前端团队。他们其中有个业务需要依靠后台来支持，但他们的后台人力很紧缺没有办法马上投入支持。于是他们的前端就借助云开发，投入1个前端工程师就迅速把这个业务给做完上线了。其实许多公司的业务都有类似的情况，公司业务发展非常快，但有的时候要前端等待后台的人力，这样就影响到整个公司的业务发展。 [图片] 可是前端的全栈开发的模式，从前端到后台，把所有的业务全都写完了，其实你会发现又回到我们最初的一个工程师大包大揽的做事情。可是这个业务是复杂的，如果没有一个工具或者一个云的基建设施去支撑这个梦想的话，其实是完全不能实现的。 面对这样的挑战，我们应该怎么答复我们的老板呢？ 腾讯云目前提供的解决方案就是云开发。 [图片] 传统开发模式会让前端变成大包大揽地做业务，其实是相当困难的，因为一方面要开发前端和后端的逻辑，还要处理所有的运维的事情，靠一个人是不可能的，所以才有了现在这样的传统分工模式，就是前端、后台、运维。如果把这个业务用上云开发的话，我们主要关心的只有一小部分，主要都是我们的业务逻辑。至少只要这个工程师能够懂Node.js，基本上就可以把服务稳定、性能卓越和有一定安全性的小程序应用独立开发出来。 云开发的开发模式真正可以实现前端工程师全栈开发的理想模式。

各位微信开发者 以下是微信卡券将不再支持新申请开通使用“优惠券”功能及上周问题反馈（11.02-11.06），希望同大家一同打造小程序生态。 微信卡券将不再支持新申请开通使用“优惠券”功能因“微信卡券>优惠券”产品能力未来将统一升级为“微信支付优惠券”，12月10日0点起，“微信卡券>优惠券”功能将不再支持新商户开通，该功能后续将陆续下线。其他微信卡券功能暂无变化。本次调整详细内容如下： 12月10日0点起，商户可正常申请开通“微信卡券”功能，申请开通后，“优惠券”功能将不再支持使用。新开通卡券功能的商户使用“会员卡”、“礼品卡”或“票证”等能力不受影响；历史已开通卡券功能的商户，可继续正常使用“卡券>优惠券”功能（包含新增、发放和核销），不受本次调整影响；微信卡券>优惠券功能入口： [图片] 受影响的优惠券： [图片] 如商户有在微信生态内发放优惠券的需求，可使用微信支付优惠券：商家券或支付券（即代金券）。如需了解更多，可查阅微信支付优惠券产品功能介绍 上周问题反馈和处理进度（11.02-11.06）已修复的问题textarea 组件修改某些样式时会失效 查看详情 picker 限制的问题 查看详情 新版 canvas 无法加载多张图片的问题 查看详情 小游戏销毁camera再创建时获取不到帧数据的问题 查看详情 cover-view外层有时候 position:fixed 无效的问题 查看详情 swiper组件 指示点被swiper-item覆盖的问题 查看详情 地图自定义 callout 溢出的问题 查看详情 移动端链接快速授权的文档URL示例多了个auth_type参数的问题 查看详情 小程序订阅消息无法添加的问题 查看详情 iOS录音，视频，文件均无法选择提交的问题 查看详情 修复中的问题 竖版游戏配置resizable为true后,pc端变横版,显示不全的问题 查看详情 iOS微信7.0.17上JSSDK出现BUG：WeixinJSBridge 未定义的问题 查看详情 服务号对话助手小程序用户昵称搜索的问题 查看详情 iOS14首次进入页面掉帧严重的问题 查看详情 无法识别iPhone 12pro机型的问题 查看详情 border-radius在ios失效的问题 查看详情 输入框嵌套在自定义组件内部时英文输入存在bug的问题 查看详情 需求反馈需求已支持 iOS 支持保存 gif & webp 到相册 查看详情 swiper 支持双指滑动 查看详情 video 组件支持投屏功能 查看详情 需求评估中顾问为什么无法收到顾客发出的位置信息 查看详情 云存储可以灵活设计文件权限的需求 查看详情 原创文章类别能否加一个设计的选项的需求 查看详情 增加同一分组内“图片批量删除”功能的需求 查看详情 微信团队 2020.11.12

系统官方可以开通这个功能

小程序中无法长按识别二维码加微信好友 希望微信能开通这个功能

image标签有一个属性show-menu-by-longpress="true" 可以长按识别小程序码，但是不是别个人二维码 ，previewImage这个方法也用了，但是还是不识别个人二维码，请问大神怎么解决

同一主体下的小程序如何跳转到公众号商城或H5商城页面，而不是在小程序里打开页面，是直接跳转。

[图片] H5时代用来做图表的插件有很多比如：[代码]ECharts[代码]、[代码]Bizcharts[代码]、[代码]JSCharts[代码]等，而这次的小程序本人选用了 ECharts 作为图表组件。 1、选择原因主要有3点： 官方某度在持续维护这个插件 官方推出了直接适配小程序的版本，且有demo，开盖即食，不用迁移 简单实用，覆盖面广且可通过配置控制包的大小，小程序毕竟大小有限制~ eCharts来自BAT中的B前端团队，对应的小程序版本为：echarts-for-weixin 官网地址 https://echarts.apache.org/ github地址 https://github.com/ecomfe/echarts-for-weixin 小程序demo地址 https://github.com/ecomfe/echarts-examples 2、用法 （1）官方教程 [代码]index.json[代码] 配置如下： [代码]{ "usingComponents": { "ec-canvas": "../../ec-canvas/ec-canvas" } } [代码] 这一配置的作用是，允许我们在 [代码]pages/bar/index.wxml[代码] 中使用 [代码]<ec-canvas>[代码] 组件。注意路径的相对位置要写对，如果目录结构和本例相同，就应该像上面这样配置。 [代码]index.wxml[代码] 中创建了一个 [代码]<ec-canvas>[代码] 组件： [代码]<view class="container"> <ec-canvas id="mychart-dom-bar" canvas-id="mychart-bar" ec="{{ ec }}"></ec-canvas> </view> [代码] 其中 [代码]ec[代码] 是一个我们在 [代码]index.js[代码] 中定义的对象，它使得图表能够在页面加载后被初始化并设置。 [代码]index.js[代码] 配置： [代码]function initChart(canvas, width, height, dpr) { const chart = echarts.init(canvas, null, { width: width, height: height, devicePixelRatio: dpr // 像素 }); canvas.setChart(chart); var option = { ... }; chart.setOption(option); return chart; } Page({ data: { ec: { onInit: initChart } } }); [代码] 这对于所有 ECharts 图表都是通用的，用户只需要修改上面 [代码]option[代码] 的内容，即可改变图表。[代码]option[代码] 的使用方法参见 ECharts 配置项文档。 官方demo里的一些用法指导： 如何延迟加载图表？ 参见 [代码]pages/lazyLoad[代码] 的例子，可以在获取数据后再初始化数据。 如何在一个页面中加载多个图表？ 参见 [代码]pages/multiCharts[代码] 的例子。 如何使用 Tooltip？ 目前，本项目已支持 ECharts Tooltip，但是由于 ECharts 相关功能尚未发版，因此需要使用当前本项目中 [代码]ec-canvas/echarts.js[代码]，这个文件包含了可以在微信中使用 Tooltip 的相关代码。目前在 ECharts 官网下载的 [代码]echarts.js[代码] 还不能直接替换使用，等 ECharts 正式发版后即可。 具体使用方法和 ECharts 相同，例子参见 [代码]pages/line/index.js[代码]。 如何保存为图片？ 参见 [代码]pages/saveCanvas[代码] 的例子。 （2）本人实战操作 [图片] [代码]import * as echarts from '../ec-canvas/echarts'; const app = getApp(); let chart; function initChart(canvas, width, height, dpr) { chart = echarts.init(canvas, null, { width: width, height: height, devicePixelRatio: dpr // new }); canvas.setChart(chart); chart.setOption(option); return chart; } var option = { title: { text: '智酷君 echarts 切换效果测试', left: 'center' }, tooltip: { trigger: 'item', formatter: '{a} <br/>{b}: {c} ({d}%)' }, legend: { orient: 'vertical', left: 10, data: ['AAA', 'BBB', 'CCC', 'DDD', 'EEE'] }, series: [ { name: '访问来源', type: 'pie', radius: ['50%', '70%'], avoidLabelOverlap: false, label: { show: false, position: 'center' }, emphasis: { label: { show: true, fontSize: '30', fontWeight: 'bold' } }, labelLine: { show: false }, data: [ {value: 335, name: 'AAA'}, {value: 310, name: 'BBB'}, {value: 234, name: 'CCC'}, {value: 135, name: 'DDD'}, {value: 1548, name: 'EEE'} ] } ] }; Page({ data: { ec: { onInit: initChart } }, onLoad: function () {}, //单曲线 line() { let option2 = { title: { text: '同一canvas更新成折线图', left: 'center' }, xAxis: { type: 'category', data: ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun'] }, yAxis: { type: 'value' }, series: [{ data: [820, 932, 901, 934, 1290, 1330, 1320], type: 'line' }] }; chart.setOption(option2) }, //切换柱状图 bar(){ let option3 = { title: { text: '直接更新数据，减少性能消耗', left: 'center' }, xAxis: { type: 'category', data: ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun'] }, yAxis: { type: 'value' }, series: [{ data: [120, 200, 150, 80, 70, 110, 130], type: 'bar', showBackground: true, backgroundStyle: { color: 'rgba(220, 220, 220, 0.8)' } }] }; chart.setOption(option3) } }) [代码] 建议大家尽量使用同一个canvas对象来切换不同的图表效果，而不是初始加载多个不同的，我们可以将 [代码]chart[代码] 对象设置为全局，然后通过 [代码]chart.setOption()[代码] 的方法来更新配置数据，可以减少性能消耗避免闪退等 （3）代码片段 代码段：https://developers.weixin.qq.com/s/OOTwnsms7Cin 建议将IDE工具升级到 1.02.18以上，避免一些BUG [图片] 3、Tips （1）包大小可以配置 在线定制地址： https://echarts.apache.org/zh/builder.html [图片] [图片] 通过选择和配置想要的功能，可以大大减少原本JS包的尺寸。 （2）Canvas 2d 版本要求 最新版的 ECharts 微信小程序支持微信 Canvas 2d，当用户的基础库版本 >= 2.9.0 且没有设置 [代码]force-use-old-canvas="true"[代码] 的情况下，使用新的 Canvas 2d（默认）。 使用新的 Canvas 2d 可以提升渲染性能，解决非同层渲染问题，强烈建议开启 如果仍需使用旧版 Canvas，使用方法如下： [代码]<ec-canvas id="xxx" canvas-id="xxx" ec="{{ ec }}" force-use-old-canvas="true"></ec-canvas> [代码] （3）数据点过多造成闪退和卡死 本人简单测试了下，iphone7p手机在[代码]1500个[代码]左右数据点的时候，出现了小程序闪退，iphoneX 测试下来大概在[代码]2500个[代码]左右，猜测可能由于微信本身给小程序的内存有限，所以建议大家控制数据点的个数 （4）单页面图表canvas加载过多卡死 建议单页面图表加载不要超过[代码]5个canvas[代码]，尽可能共用一个图表Canvas对象，通过动态更新数据的方式来展示内容（还有帅气的特效），如果一定要加载多个canvas的话，建议控制数量，提供复用性~ 看完觉得有帮助记得点个赞哦~ 你的赞是我继续分享的最大动力！^-^

现在的开发工具里面，加上wx-open-launch-weapp这个标签之后，里面图片文字显示不出来（不知道是我代码问题还是什么，不过实际手机是可以的)，点击不进入对应小程序。 这个是否能够未来处理下？

小程序模板消息能力在帮助小程序实现服务闭环的同时，也存在一些问题，如： 1. 部分开发者在用户无预期或未进行服务的情况下发送与用户无关的消息，对用户产生了骚扰； 2. 模板消息需在用户访问小程序后的 7 天内下发，不能满足部分业务的时间要求。 为提升小程序模板消息能力的使用体验，我们对模板消息的下发条件进行了调整，由用户自主订阅所需消息。 一次性订阅消息 一次性订阅消息用于解决用户使用小程序后，后续服务环节的通知问题。用户自主订阅后，开发者可不限时间地下发一条对应的服务消息；每条消息可单独订阅或退订。 [图片] （一次性订阅示例） 长期性订阅消息 一次性订阅消息可满足小程序的大部分服务场景需求，但线下公共服务领域存在一次性订阅无法满足的场景，如航班延误，需根据航班实时动态来多次发送消息提醒。为便于服务，我们提供了长期性订阅消息，用户订阅一次后，开发者可长期下发多条消息。 目前长期性订阅消息仅向政务民生、医疗、交通、金融、教育等线下公共服务开放，后期将逐步支持到其他线下公共服务业务。 调整计划 小程序订阅消息接口上线后，原先的模板消息接口将停止使用，详情如下： 1. 开发者可登录小程序管理后台开启订阅消息功能，接口开发可参考文档：《小程序订阅消息》 2. 开发者使用订阅消息能力时，需遵循运营规范，不可用奖励或其它形式强制用户订阅，不可下发与用户预期不符或违反国家法律法规的内容。具体可参考文档：《小程序订阅消息接口运营规范》 3. 原有的小程序模板消息接口将于 2020 年 1 月 10 日下线，届时将无法使用此接口发送模板消息，请各位开发者注意及时调整接口。            微信团队 2019.10.12

- 当前 Bug 的表现（可附上截图） [图片] 图1：开发工具正常 图2：移动端表现 [图片] 在社区也找到相关的提问，但官方始终没关注该bug。希望多关注开发者提出的bug - 预期表现 - 复现路径 - 提供一个最简复现 Demo

[图片] [图片] 为什么关联公众号组件不显示 <view class="home-top" style="width:100%"> <official-account bindload="officialSucc" binderror="officialFail"></official-account> </view> 我现在没有关注这个微信公众号

昨天半夜被头儿一阵急匆匆的电话叫醒 最近由于疫情，截止今天（复工的第三周了），小伙伴们都在家办(划)公(水)，有些需求调研可能都是头儿独自来撑着，头儿自报家门后问我，网页里面能不能直接打开小程序或者网页分享到朋友圈然后打开小程序，我不好掐指算，头儿调研的功能，但是很肯定的告诉头儿，不行，不行，你别胡来。 当然我给头儿的回复是肯定不可以这么操作，从技术角度是办不到的。 言归正传，那么从微信H5打开小程序有几种实现方式呢？目前我想到有两种，如果还有其他方式，可以评论区留言 1、微信H5内部，放一张小程序码 图片，然后提示用户长按小程序码图片体验小程序 2、微信H5提供链接，跳转到公众号MP文章，也就是公众号内部文章，这个时候由于公众号是可以通过下面截图中文字、图片、小程序卡片、小程序码四种方式唤醒小程序的。 [图片] 占位、 如果还有其他技术可行性方案，欢迎大家在评论区留言，非常感谢。

问题：最近开发项目的时候，因为将textarea放到了弹层里，结果出现了弹层隐藏过程中textarea滞留的问题，滑动页面时，仍然穿透到最顶层，体验非常差。 解决方案：在弹层收起动画开始的时候，将textarea隐藏掉，弹出弹层的时候再显示出来。 代码如下： <form bindsubmit='postSave' report-submit> <view class="postText"> <!--使用showTextarea控制textarea的显示和隐藏--> <textarea wx:if="{{showTextarea}}" class="textarea" name="posttext" placeholder="写下今日小确幸，最多输入60个字" maxlength="60" bindinput="bindinput" hold-keyboard></textarea> </view> <view class="postPublic"> <text>发布到广场</text> <switch class="switch-input" color="#7dbfb5" name="postpublic" checked="{{postData.public}}" bindchange="switchChange"></switch> </view> <button wx:if="{{userAuth}}" disabled="{{typing}}" hover-class="none" form-type="submit">发布</button> </form> data: { showTextarea: false //解决Textarea层级过高问题，导致关闭动画时滞留 }, close() { this.setData({ showTextarea: false }) // 弹窗动画略 }, open() { this.setData({ showTextarea: true }) // 弹窗动画略 }

众所周知，小程序当中有一类特殊的内置组件——原生组件，这类组件有别于 WebView 渲染的内置组件，他们是交由原生客户端渲染的。原生组件作为 Webview 的补充，为小程序带来了更丰富的特性和更高的性能，但同时由于脱离 Webview 渲染也给开发者带来了不小的困扰。在小程序引入「同层渲染」之前，原生组件的层级总是最高，不受 [代码]z-index[代码] 属性的控制，无法与 [代码]view[代码]、[代码]image[代码] 等内置组件相互覆盖， [代码]cover-view[代码] 和 [代码]cover-image[代码] 组件的出现一定程度上缓解了覆盖的问题，同时为了让原生组件能被嵌套在 [代码]swiper[代码]、[代码]scroll-view[代码] 等容器内，小程序在过去也推出了一些临时的解决方案。但随着小程序生态的发展，开发者对原生组件的使用场景不断扩大，原生组件的这些问题也日趋显现，为了彻底解决原生组件带来的种种限制，我们对小程序原生组件进行了一次重构，引入了「同层渲染」。 相信已经有不少开发者已经在日常的小程序开发中使用了「同层渲染」的原生组件，那么究竟什么是「同层渲染」？它背后的实现原理是怎样的？它是解决原生组件限制的银弹吗？本文将会为你一一解答这些问题。 什么是「同层渲染」? 首先我们先来了解一下小程序原生组件的渲染原理。我们知道，小程序的内容大多是渲染在 WebView 上的，如果把 WebView 看成单独的一层，那么由系统自带的这些原生组件则位于另一个更高的层级。两个层级是完全独立的，因此无法简单地通过使用 [代码]z-index[代码] 控制原生组件和非原生组件之间的相对层级。正如下图所示，非原生组件位于 WebView 层，而原生组件及 [代码]cover-view[代码] 与 [代码]cover-image[代码] 则位于另一个较高的层级： [图片] 那么「同层渲染」顾名思义则是指通过一定的技术手段把原生组件直接渲染到 WebView 层级上，此时「原生组件层」已经不存在，原生组件此时已被直接挂载到 WebView 节点上。你几乎可以像使用非原生组件一样去使用「同层渲染」的原生组件，比如使用 [代码]view[代码]、[代码]image[代码] 覆盖原生组件、使用 [代码]z-index[代码] 指定原生组件的层级、把原生组件放置在 [代码]scroll-view[代码]、[代码]swiper[代码]、[代码]movable-view[代码] 等容器内，通过 [代码]WXSS[代码] 设置原生组件的样式等等。启用「同层渲染」之后的界面层级如下图所示： [图片] 「同层渲染」原理 你一定也想知道「同层渲染」背后究竟采用了什么技术。只有真正理解了「同层渲染」背后的机制，才能更高效地使用好这项能力。实际上，小程序的同层渲染在 iOS 和 Android 平台下的实现不同，因此下面分成两部分来分别介绍两个平台的实现方案。 iOS 端 小程序在 iOS 端使用 WKWebView 进行渲染的，WKWebView 在内部采用的是分层的方式进行渲染，它会将 WebKit 内核生成的 Compositing Layer（合成层）渲染成 iOS 上的一个 WKCompositingView，这是一个客户端原生的 View，不过可惜的是，内核一般会将多个 DOM 节点渲染到一个 Compositing Layer 上，因此合成层与 DOM 节点之间不存在一对一的映射关系。不过我们发现，当把一个 DOM 节点的 CSS 属性设置为 [代码]overflow: scroll[代码] （低版本需同时设置 [代码]-webkit-overflow-scrolling: touch[代码]）之后，WKWebView 会为其生成一个 [代码]WKChildScrollView[代码]，与 DOM 节点存在映射关系，这是一个原生的 [代码]UIScrollView[代码] 的子类，也就是说 WebView 里的滚动实际上是由真正的原生滚动组件来承载的。WKWebView 这么做是为了可以让 iOS 上的 WebView 滚动有更流畅的体验。虽说 [代码]WKChildScrollView[代码] 也是原生组件，但 WebKit 内核已经处理了它与其他 DOM 节点之间的层级关系，因此你可以直接使用 WXSS 控制层级而不必担心遮挡的问题。 小程序 iOS 端的「同层渲染」也正是基于 [代码]WKChildScrollView[代码] 实现的，原生组件在 attached 之后会直接挂载到预先创建好的 [代码]WKChildScrollView[代码] 容器下，大致的流程如下： 创建一个 DOM 节点并设置其 CSS 属性为 [代码]overflow: scroll[代码] 且 [代码]-webkit-overflow-scrolling: touch[代码]； 通知客户端查找到该 DOM 节点对应的原生 [代码]WKChildScrollView[代码] 组件； 将原生组件挂载到该 [代码]WKChildScrollView[代码] 节点上作为其子 View。 [图片] 通过上述流程，小程序的原生组件就被插入到 [代码]WKChildScrollView[代码] 了，也即是在 [代码]步骤1[代码] 创建的那个 DOM 节点对应的原生 ScrollView 的子节点。此时，修改这个 DOM 节点的样式属性同样也会应用到原生组件上。因此，「同层渲染」的原生组件与普通的内置组件表现并无二致。 Android 端 小程序在 Android 端采用 chromium 作为 WebView 渲染层，与 iOS 不同的是，Android 端的 WebView 是单独进行渲染而不会在客户端生成类似 iOS 那样的 Compositing View (合成层)，经渲染后的 WebView 是一个完整的视图，因此需要采用其他的方案来实现「同层渲染」。经过我们的调研发现，chromium 支持 WebPlugin 机制，WebPlugin 是浏览器内核的一个插件机制，主要用来解析和描述embed 标签。Android 端的同层渲染就是基于 [代码]embed[代码] 标签结合 chromium 内核扩展来实现的。 [图片] Android 端「同层渲染」的大致流程如下: WebView 侧创建一个 [代码]embed[代码] DOM 节点并指定组件类型； chromium 内核会创建一个 [代码]WebPlugin[代码] 实例，并生成一个 [代码]RenderLayer[代码]； Android 客户端初始化一个对应的原生组件； Android 客户端将原生组件的画面绘制到步骤2创建的 [代码]RenderLayer[代码] 所绑定的 [代码]SurfaceTexture[代码] 上； 通知 chromium 内核渲染该 [代码]RenderLayer[代码]； chromium 渲染该 [代码]embed[代码] 节点并上屏。 [图片] 这样就实现了把一个原生组件渲染到 WebView 上，这个流程相当于给 WebView 添加了一个外置的插件，如果你有留意 Chrome 浏览器上的 pdf 预览，会发现实际上它也是基于 [代码]<embed />[代码] 标签实现的。 这种方式可以用于 map、video、canvas、camera 等原生组件的渲染，对于 input 和 textarea，采用的方案是直接对 chromium 的组件进行扩展，来支持一些 WebView 本身不具备的能力。 对比 iOS 端的实现，Android 端的「同层渲染」真正将原生组件视图加到了 WebView 的渲染流程中且 embed 节点是真正的 DOM 节点，理论上可以将任意 WXSS 属性作用在该节点上。Android 端相对来说是更加彻底的「同层渲染」，但相应的重构成本也会更高一些。 「同层渲染」 Tips 通过上文我们已经了解了「同层渲染」在 iOS 和 Android 端的实现原理。Android 端的「同层渲染」是基于 chromium 内核开发的扩展，可以看成是 webview 的一项能力，而 iOS 端则需要在使用过程中稍加注意。以下列出了若干注意事项，可以帮助你避免踩坑： Tips 1. 不是所有情况均会启用「同层渲染」 需要注意的是，原生组件的「同层渲染」能力可能会在特定情况下失效，一方面你需要在开发时稍加注意，另一方面同层渲染失败会触发 [代码]bindrendererror[代码] 事件，可在必要时根据该回调做好 UI 的 fallback。根据我们的统计，目前同层失败率很低，也不需要太过于担心。 对 Android 端来说，如果用户的设备没有微信自研的 [代码]chromium[代码] 内核，则会无法切换至「同层渲染」，此时会在组件初始化阶段触发 [代码]bindrendererror[代码]。而 iOS 端的情况会稍复杂一些：如果在基础库创建同层节点时，节点发生了 WXSS 变化从而引起 WebKit 内核重排，此时可能会出现同层失败的现象。解决方法：应尽量避免在原生组件上频繁修改节点的 WXSS 属性，尤其要尽量避免修改节点的 [代码]position[代码] 属性。如需对原生组件进行变换，强烈推荐使用 [代码]transform[代码] 而非修改节点的 [代码]position[代码] 属性。 Tips 2. iOS 「同层渲染」与 WebView 渲染稍有区别 上文我们已经了解了 iOS 端同层渲染的原理，实际上，WebKit 内核并不感知原生组件的存在，因此并非所有的 WXSS 属性都可以在原生组件上生效。一般来说，定位 (position / margin / padding) 、尺寸 (width / height) 、transform (scale / rotate / translate) 以及层级 (z-index) 相关的属性均可生效，在原生组件外部的属性 (如 shadow、border) 一般也会生效。但如需对组件做裁剪则可能会失败，例如：[代码]border-radius[代码] 属性应用在父节点不会产生圆角效果。 Tips 3. 「同层渲染」的事件机制 启用了「同层渲染」之后的原生组件相比于之前的区别是原生组件上的事件也会冒泡，意味着，一个原生组件或原生组件的子节点上的事件也会冒泡到其父节点上并触发父节点的事件监听，通常可以使用 [代码]catch[代码] 来阻止原生组件的事件冒泡。 Tips 4. 只有子节点才会进入全屏 有别于非同层渲染的原生组件，像 [代码]video[代码] 和 [代码]live-player[代码] 这类组件进入全屏时，只有其子节点会被显示。 [图片] 总结 阅读本文之后，相信你已经对小程序原生组件的「同层渲染」有了更深入的理解。同层渲染不仅解决了原生组件的层级问题，同时也让原生组件有了更丰富的展示和交互的能力。下表列出的原生组件都已经支持了「同层渲染」，其他组件（ textarea、camera、webgl 及 input）也会在近期逐步上线。现在你就可以试试用「同层渲染」来优化你的小程序了。 支持同层渲染的原生组件 最低版本 video v2.4.0 map v2.7.0 canvas 2d（新接口） v2.9.0 live-player v2.9.1 live-pusher v2.9.1

这是我 组件调用 和 访问的实例结果 对应的数据是访问到了 (__data__ )中 但是没有方法 [图片] [图片] 这是官方给的方法列表 [图片] 实在不知道问题出在哪里....求大佬解答

我已经在.json上添加了[图片]并且wxml上也有这个组件[图片] 但是调用this.selectComponent('#article')的时候就报错。[图片] 看了下其他答案[图片]

[图片] [图片]返回的两个地址码不对

微信小程序里支持长按公众号二维码进入公众号么，或者长按APP二维码下载APP。

在页面中插入VIDEO组件，滑动页面。视频滑动到屏幕上半部分时，显示控制层；但是滑动到屏幕下半部分时，控制层消失。请问这个是怎么回事？怎么解决？ [图片][图片][图片] PS：VIDEO在scroll-view内部

Github项目地址：https://github.com/czcaiwj/calendar 「极点日历」插件支持 1900 年 1 月 ~ 2099 年 12 月这两百年间的公历和农历显示，插件提供了丰富的可配置属性，包括日期的显示方式、选择范围、是否显示农历等，可自定义来适配不同的使用场景。 插件ID：wx92c68dae5a8bb046 版本历史： v1.0.0 完成插件基本功能 v1.1.0 修复日期点击bug v1.1.1 修复结束日期bug v1.1.2 修复日期显示不对齐的问题，修复农历计算中偶发性bug v1.1.3 修复日历1月和12月点击上一年日期和下一年日期年份返回错误的bug（已提交，审核中） 具体的使用方法，可以参考下面的接口文档和用法例子 1、添加插件到自己的小程序 2、日历属性接口文档 3、日历事件用法 4、自定义日历样式 demo1 [图片] demo2 [图片] demo3 [图片] demo4 [图片] demo5 [图片] demo6 [图片] demo7 [图片]

开发一个小程序管理平台，其他小程序管理员只需一次授权给第三方，第三方平台即可帮助他发布小程序，不同管理员的配置参数不同，其他功能都基本相同 开发步骤： 一、注册开放平台： 到微信开放平台注册账号 ：https://open.weixin.qq.com/cgi-bin/readtemplate?t=regist/regist_tmpl&lang=zh_CN 二、申请第三方平台开发 申请第三方平台必须拥有一定的开发者资质，必须先通过开发者资质认证，才可以开始第三方平台开发，在开发平台账号管理中可进行资质认证 三、创建第三方平台 申请完成后，在开发平台的管理中心，点击第三方平台，在下方可看到创建第三方按钮 [图片] 点击创建第三方平台，进入下方页面，选择平台型服务商， [图片] 1.填写基本信息，与定制化服务商一致 2.选择权限，只能选择业务必须的权限集，否则无法通过审核，公众号或小程序也可能会拒绝授权给你。（权限集是公众号或小程序的权限集合，用于实现业务） 3.填写开发资料 4.开发资料 ①授权发起也域名（即用户打开我们自己的授权页域名） ②授权事件接收URL（我们接收所有授权小程序或公众号取消授权通知、授权成功通知、授权更新通知事件的url地址 ， 包括接收微信平台推送的ticket） ③消息与事件接收URL （我们接收所有授权小程序或公众号的消息和事件推送，例如客服消息 微信就会推送到这个地址上） 这里要注意一点：该参数按规则填写（需包含/$APPID$，如www.abc.com/$APPID$/callback） 填写的地址需要包含/$APPID$ 我们后续可以用nginx 重写地址 把访问指向同一个地址就可以了 例如：填写的地址是 www.abc.com/msg/$APPID$/msgEventPath.php    nginx重写地址：  rewrite ^/msg/(.)/(.).php /msgEventPath.php last; ④其它按照提示填写就可以了，添加上白名单ip 然后提交审核就可以了，如果信息没有问题是马上就能审核成功的，然后再管理中心的第三方平台即可看到改第三方服务商，详情里面即有改第三方平台相关的配置信息 四、小程序管理员授权给第三方平台 只有小程序管理员授权给第三方，第三方才能为该小程序发布，更新部署代码。 授权开发步骤： 1.保存component_verify_ticket， 微信端会定时推送消息到配置好的授权事件接收URL（创建三方平台时填写的，可在该三方详情中查看） 上，我们需要保存这个component_verify_ticket和 不断更新，component_verify_ticket必须保持是微信端推送的最新一个 2.用component_verify_ticket去换取第三方平台的token（第三方平台指的就是我们自己在开发的平台）token是有有效期的，所以我们要保存它的过期时间，并将token做缓存，当token没过期时就不用再去换取，反之我们要利用最新的component_verify_ticket去重新获取token 3.换取预授权码pre_auth_code，pre_auth_code是用来换取微信端的授权二维码的 4.跳转到授权页面（两种方式），建议第二种，方便 用户授权的时候会先打开我们自己的一个页面 （例如 http://www.abc.com/authorization.php ），这个页面里需要做一个按钮或者用js去跳转到微信的授权页面 ①扫码授权 ：跳转后得到授权码，注意这个页面只能用网页访问，小程序访问不了，因为不能将微信域名配置为业务域名用户扫码后 就可以授权给第三方平台了 https://mp.weixin.qq.com/cgi-bin/componentloginpage?component_appid=xxxx&pre_auth_code=xxxxx&redirect_uri=xxxx&auth_type=xxx。 ②点击移动端链接快速授权https://mp.weixin.qq.com/safe/bindcomponent?action=bindcomponent&auth_type=3&no_scan=1&component_appid=xxxx&pre_auth_code=xxxxx&redirect_uri=xxxx&auth_type=xxx&biz_appid=xxxx#wechat_redirect 请求参数（两种方式一样） component_appid 第三方平台方appid pre_auth_code 预授权码 redirect_uri 回调URI 必须和授权地址同一个域名 auth_type 要授权的帐号类型：1则商户点击链接后，手机端仅展示公众号、2表示仅展示小程序，3表示公众号和小程序都展示。如果为未指定，则默认小程序和公众号都展示。第三方平台开发者可以使用本字段来控制授权的帐号类型。 前四步总结（移动端快速授权流程）： 用户自己获取授权连接： 需要后台配合，给出一个接口，请求该接口则直接返回最新的预授权码（pre_auth_code），拿到授权码之后，再通过拼接返回一个授权地址，跳转到改地址，即为授权页面下方图二 ，用户点击授权即可授权给第三方。用户点击授权后，授权页会自动跳转进入回调URI，并在URL参数中返回授权码和过期时间(redirect_url?auth_code=xxx&expires_in=600)，我们可以通过  $GET[‘authcode’] 去获取授权用户的小程序或二维码 调用接口的accesstoken（有效期两小时） 并将其保存/更新，然后我们就可以获取授权用户小程序或公众号的信息 [图片] 5.使用授权码换取公众号或小程序的接口调用凭据和授权信息 接口调用请求说明 http请求方式: POST（请使用https协议） https://api.weixin.qq.com/cgi-bin/component/api_query_auth?component_access_token=xxxx（component_access_token在第二步可获取） POST请求参数示例: { “component_appid”:“appid_value” ,//第三方平台appid “authorization_code”: “auth_code_value”//授权code,会在授权成功时返回给第三方平台 } 请求成功后拿到 authorizer_access_token：授权方接口调用凭据（在授权的公众号或小程序具备API权限时，才有此返回值），也简称为令牌，后面调用小程序待开发的api中使用， authorizer_refresh_token：接口调用凭据刷新令牌（在授权的公众号具备API权限时，才有此返回值），刷新令牌主要用于第三方平台获取和刷新已授权用户的access_token，只会在授权时刻提供，请妥善保存。 一旦丢失，只能让用户重新授权，才能再次拿到新的刷新令牌 五、小程序模板开发 第三方平台帮助旗下已授权的小程序进行代码管理时，需先开发完成小程序模版，再将小程序模版部署到旗下小程序帐号中，具体流程如下： 第一步：绑定开发小程序 （1）第三方平台的开发人员需先到微信公众平台（mp.weixin.qq.com）申请一个普通的小程序并完善小程序的头像、昵称、简介、服务类目等信息。 （2）进入微信开放平台，在第三方平台详情中，将该小程序添加为开发小程序。 注意：绑定为开发小程序后，该小程序的在开发工具中上传，代码会直接上传到开放平台，不会上传到公众平台。 第二步：小程序模版的开发和上传 使用开发小程序的开发者微信号登录微信web开发者工具（IDE），开发者工具中按照正常的小程序开发流程进行代码开发和调试。开发完成后，在开发工具中点击上传。更新模板后需要更部署到旗下小程序之前必须上传到模板库。注意：上传时版本号要求不一样，一样的版本号会被默认为同一版本，判断为管理员没有更新 第三步：添加到小程序模版库，获得模版ID 从开发者工具中上传的代码，会先存在草稿箱中，每个开发小程序只保留最新一份上传记录。开发者可将草稿箱中的代码添加到小程序模版库中，小程序模版库中的模版不会被覆盖。最多可以有五十个代码模版，添加后可以获得模版ID（TemplateID） 拿到模板ID后，再加上之前获取到的authorizer_access_token（令牌），就能为授权过给该第三方平台的小程序部署代码了。 六、为旗下小程序进行代码管理 举个例子：为授权的小程序帐号上传小程序代码 1、为授权的小程序帐号上传小程序代码 请求方式: POST（请使用https协议） https://api.weixin.qq.com/wxa/commit?access_token=TOKEN POST数据示例 { “template_id”:0, “ext_json”:“JSON_STRING”, //ext_json需为string类型，请参考下面的格式 “user_version”:“V1.0”, “user_desc”:“test”, } 参数说明: access_token 请使用第三方平台获取到的该小程序授权的authorizer_access_token template_id 代码库中的代码模版ID ext_json 第三方自定义的配置 user_version 代码版本号，开发者可自定义（长度不要超过64个字符） user_desc 代码描述，开发者可自定义 通过此请求，第三方平台会自动将模板中的代码自动部署到授权给该第三方的小程序上 更多代码管理查看文档 https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&t=resource/res_list&verify=1&id=open1453779503&token=1a70ae891ca6e0339cf56bd1b3c322b0ec86eec9&lang= 持续更新中… 相关文章：https://developers.weixin.qq.com/community/develop/doc/0000ee097e0f00dcd55b8e40856800?jumpto=reply&parent_commentid=00004e9efb84388cd95ba8023514&commentid=000c0623e98068f0e85be2b97564