视频号直播里的组件是否可以一键点击跳转到小程序首页，用户在小程序里进行抽奖，玩游戏等互动玩法。 是否也要满足2个的主体或者超级管理者一致才行。

微信团队在1月27日发布《服务号订阅通知灰度测试》公告，宣布将在2021年1月27日0:00至4月30日24:00进行服务号订阅通知功能的灰度测试，并在灰度测试结束后另行公布订阅通知和模板消息功能的调整策略。 近几年，随着微信订阅号的改版、小程序模板消息功能的调整，大部分需要实时将消息触达用户的公司，都选择了依托微信服务号模板消息来开展业务。 虽然此功能还未明确将替代模板消息，但仍值得思考一下：此举对微信、开发者、运营者、用户，分别意味着什么？ 从微信来看 微信把订阅通知的功能初衷定义为：提升用户体验，减少开发者对用户的骚扰行为，并增加营销类消息的推送能力。 订阅通知是一个用户主动订阅、服务号按需下发的通知能力。 -微信团队 1.消息通知方式的变化 对此事件有过了解的读者会发现，微信此举并不是对模板消息进行了[升级]，而是[重构]了服务号的消息通知逻辑： 1.不能给只关注不订阅的用户发送模板消息； 2.订阅后，已关注服务号的用户，消息通知下发到服务号内，未关注的下发到服务通知； 3.非公共服务类服务号，根据微信目前的规定，每次给用户发送消息通知都需要被订阅，但用户可以自行选择长期订阅。 简单来说，服务号的消息通知方式向小程序看齐了，不能直接通过服务号向已关注未订阅的用户推送模板消息，但用户订阅消息后取关服务号仍可以对其发送消息通知。 例如：改版后即使关注了XX银行信用卡中心，但未订阅，也无法通过服务号收到动账、还款的消息通知；但订阅取关后，仍能收到服务号的消息通知。 2.治理生态的决心-顶住压力做变革 据笔者的非官方统计，国内共100W+开发者服务于微信生态，生态内共有1000W+公众号，其中服务号占比超过60%。(此处并未统计服务号粉丝总和) 从上面所描述的内容中，可以得出一个结论： 微信在服务号开发者、用户基数如此之大，且大部分公司业务基本成熟稳定的情况下，决定灰度测试订阅通知，可见其治理模板消息滥用，过度、恶意营销的决心。 从开发者来看 笔者个人认为，微信团队在模板消息被滥用这个问题上，有一些过度武断了。为了治理1%的滥用情况，影响了99%的开发者的直接利益。 1.牵一发而动全身 对于服务号的开发者而言，这个简单的调整可以被称作颠覆了绝大部分公司的[业务根基]。 有很多初创公司，整体收入都是依托于服务号来进行的，甚至强依赖模板消息开展业务。甚至一些具有一定规模、业务成熟的公司，很多系统的功能都是围绕模板消息进行开发的，二次开发成本不可谓不大。 2.被迫改变的无奈-APP开发和短信平台的春天 在微信团队发出公告后，微信开放社区中的状况可以用“炸锅”来形容。并且在公告后，却无法明确调整策略，导致开发者无法决策是否进行二次开发。如果在开发完后，微信选择暂时不做出调整，那之前所付出的开发成本都将打水漂。 在此事件后，很多开发者都选择了将消息通知方式更换为短信通知的方式，但短信发送费用可能会导致运维成本的直线上升。更有甚者，直接选择了脱离微信生态，开发独立APP处理业务。 如果按照现在的状况发展，笔者个人认为将会为APP开发服务商和第三方短信平台带来更高，甚至激增的收益。 从运营者来看 对于服务号运营者来说，这个变化“悲喜兼集”，悲在运营的难度被大大增加了，但如果真的仔细研究了新的规则，就会发现运营的玩法更加多元化了。 1.运营难度增加 以往的服务号运营，只需要考虑如何将用户导流到号内，并保证留存率就可以了。在新功能出现后，运营者可能还需要做出很多的调整，来引导用户去订阅自己的消息通知，才能够完成业务闭环。 同时，运营者要关注的数据将不再是以前单纯的关注、取关数，势必会增加消息订阅数量、取消订阅数量，来保证消息通知的触达率。 之前通过模板消息来完成营销、实现业务的服务号，必须要因此而“改头换面”，以实现存活在微信生态内的目的。 2.运营方式的变化-新玩法的出现 细心的读者会发现，消息通知方式改变后，服务号运营玩法出现了新的途径。以前为了给用户发送消息通知，大多数服务号都采用引导关注的方式，但订阅通知上线后，即便用户不关注服务号，订阅消息后仍可通过服务通知的方式获取消息，具体逻辑见下图。 [图片] 根据新的消息发送方式，运营者可以直接绕过关注服务号这一步，直接采用H5页面引导订阅的方式，对用户发送消息，甚至探索更多的玩法。 从用户来看 微信团队认为：从用户的角度来看，部分用户在无预期的情况下，收到了与自己无关的信息，对用户造成了骚扰。 微信作为国民的刚需应用，笔者本人也是重度用户之一。个人认为此变化有利有弊。 1.操作成本增加 大多用户或多或少都有一些需要接收的消息通知，例如信用卡的消费提醒。按照微信现在的文档中提供的能力，在微信改变通知方式后，用户必须挨个打开需要接收消息的服务号，寻找订阅入口，并手动订阅，才可以继续接收消息通知。 这种方式无疑加大了用户的操作成本，在之前关注的服务号中需要重新订阅一遍，在新关注的服务号中，如果想要接收消息通知，还需要额外做出订阅的操作。 另外微信针对订阅功能，在开发文档中给开发者设立了一些门槛，这也将造成对用户的不友好。 详见下图，一个开发者为了满足微信门槛做出的Demo。笔者预估每个功能给用户增加的操作时间超过15秒。 [图片] 2.使用方式的变化-消息列表更“干净”了 通知方式改变后，用户如果只想要接收服务号内和自己相关的消息，而不想接收群发的文章等。可以选择只订阅消息，不关注服务号。 在互联网时代，各种信息的狂轰乱炸给网民造成了不小的压力。这对用户来说，信息的接收可以更加的随心所欲，减轻了用户的信息压力。 最后 希望微信团队能够慎重考虑调整策略，甚至可以考虑沿用原来的模板消息推送方式，仅增加“拒收通知”的选项来逐步解决生态中的问题。 个人认为，微信此举已经展示了自己的决心，建议大家尽早的未雨绸缪，以避免自己的业务受到影响。 笔者从事行业对于模板消息属于强需求，所以将会在近期为大家提供一个自己结合微信文档所总结的产品设计方案。 作者：氟西汀，公众号：氟西汀终究还是没了 学艺不精，欢迎批评。如想交流产品设计方案，欢迎留言。 未经授权禁止转载

企业视频号认证的时候，需要与公众号名称一致，但是提我们名称已经被占用。 我们的公众号名称【龙岩人才网】已经认证了5年，也有相关的营业执照、政府授权名称书（因为涉及到地方）、电信许可证等资质证明。 现在处理方式： 一、去了占用我们视频号的企业下投诉占用我们的名称（他们也没有发内容，就占用名称） 处理结果：说我们没有提交公众号后台截图等营业执照被驳回了（提交了两次，每次都给截图和资料） 二、去腾讯客服小程序提交了工单 一直没有结果。 大家有没有其他的办法，主要是企业认证，还需要和公众号名称一样，如果不一样我们也就换其他名字了。现在要一样 ，我们被迫就一定需要使用这个名称。

目前的文档要求在onLaunch中调用miniShopPlugin.initApp(this, wx)来引入交易组件，但是目前碰到有两个疑问 不调用miniShopPlugin.initApp好像也可以正常加载组件并使用，但是这样会有其他什么问题吗？如果执行miniShopPlugin.initApp来初始化，会造成阿拉丁sdk报错，即使改用插件接入的方式也是一样。Cannot read property 'scene' of undefined TypeError: Cannot read property 'scene' of undefined     at ve.i (http://127.0.0.1:28672/appservice/lib/ald-stat.js:78:15)     at ve.A.e.onShow (http://127.0.0.1:28672/appservice/lib/ald-stat.js:340:9)     at ve.<anonymous> (http://127.0.0.1:28672/appservice/__dev__/WAService.js:2:2071321)     at ve.onShow (http://127.0.0.1:28672/appservice/__onlineplugin__/wx34345ae5855f892d/1.1.25/appservice.js:6084:1388)     at new ve (http://127.0.0.1:28672/appservice/__dev__/WAService.js:2:2072100)     at Function.<anonymous> (http://127.0.0.1:28672/appservice/__dev__/WAService.js:2:2072389)     at http://127.0.0.1:28672/appservice/__dev__/WAService.js:2:2058868     at App (http://127.0.0.1:28672/appservice/lib/sensorsdata.min.js:1178:32)     at P (http://127.0.0.1:28672/appservice/lib/ald-stat.js:374:12)     at http://127.0.0.1:28672/appservice/app.js:89:1  对这个问题进行debug之后发现，调用miniShopPlugin.initApp(this, wx)初始化之后，app的onShow函数的调用参数总是为空，间接导致了 ald内部方法执行失败

如题，最近频繁出现。 代码如下，global.wxp是Promise化的wx API global.wxp.getShareInfo({ shareTicket: getApp().globalData.shareTicket }).then(res => { let apiURL = getApp().globalData.commonApiURL + '?action=s_getShareWxGID'; let apiPostData = getCommonApiSignObj({ encrypteddata: res.encryptedData, iv: res.iv, wxuid: wxuid }); global.wxp.request({ url: apiURL, header: { 'content-type': 'application/x-www-form-urlencoded', 'apisign': apiPostData.sign }, method: 'post', data: apiPostData }).then(gidRes => { }); 调用wx.getShareInfo，解密后得到的是这样的数据，没有openGId，请问这是什么情况？msgTicket我从官方文档中搜不到任何信息 array( 'watermark' => array( 'timestamp' => '1584341169', 'appid' => 'wxd747f395301bffa6', ), 'msgTicket' => 'hM0tm_V4Kz3btQdr-dnjeN95Bt73JRKTH-dTT6gvsxkpF1dUbB8NaM81oa8cmr6Yeqazlf7IQrrRPgsLG8JPaVpyiHZH0Yr3QhDYrpFsdfwe~', )

如题，想知道私密消息的验证原理，如果两个人的分享都用了同一个 activityId ，会影响验证吗？

authPrivateMessage:fail no permission 小程序私密消息验证失败 我们最近在测试私密消息，发现验证失败，不知道是不是官方接口有问题？ [图片]

[图片] 个人是没有主动点击拒收的，最近发现，许多小程序的服务通知自动拒收了？请问用户是有接受频率限制吗？还是其他什么原因？ 发现许多小程序的消息通知都被自动拒收了？

请问，能不能设置让某人看不到所有历史消息？公众号的黑名单还是有漏洞啊

想在小程序中添加一个功能，调起自己的收款码，由客户扫码支付。 整个支付流程是个人对个人，不涉及商户。 想用小程序实现是因为想记录交易双方的id及该次订单的详情。 不知道如何能实现？