1、请求分账1.1:分账失败问题如图示: [图片] 在请求多次分账接口时出现这个分账接收方与原请求不一致错误，自己针对这个message分析了半天也没找到问题所在。对于多次分账接口，请求的参数out_order_no是系统的订单号，第一分账是我们自己的订单号。但是后面每次请求分账需要使用前一次分账返回的order_id来作为out_order_no，out_order_no如果一直是我们自定义的单号，则会报错。 1.2:请求分账资金问题经常会有遇到添加了多个分账接收方然后发起分账的操作，这个时候如果其他一个失败了，很多人不清楚这笔分账是不是就直接失败了，其实是这样的，只是针对单个信息错误的分账接收方无法完成分账，但是其他正常的均是正常的进行分账的操作的。 2、分账后退款对订单进行退款时，如果订单已经分账，可以先调用分账回退接口将指定的金额从分账接收方（仅限商户类型的分账接收方）回退给本商户，然后再退款。 分账回退接口:https://pay.weixin.qq.com/wiki/doc/api/allocation.php?chapter=27_7&index=8 但是其实的话是可以先去调用退款接口的(前提是商户可用余额充足)，分账订单的退款与分账回退并无强耦合，分账回退的资金是回到商户可用余额中，分账回退可先于退款发起，可后于退款发起，或者根据分账方与商户的约定，不发起分账回退。 3、完结分账完结分账在对一个订单进行单次分账的时候其实是不需要的，在单次分账之后冻结金额其实是已经解冻了的。在对于多次分账订单的情况下，是不想在进行分账操作的时候去调用，而不是分账一次调用一次。其次的话如果直接不想对这笔订单做分账操作也是可以直接调用完结分账接口把资金解冻。

目前是选择‘总是保持以上选择，"不再询问"后，可以在设置中开启或拒绝接收，但不会再次拉起授权弹窗

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

给提问的开发者的建议： 1、审核申诉问题，建议优先走腾讯客服（工单）流程。（路径：kf.qq.com） 2、提问之前先查询文档、通过社区右上角搜索已经存在的问题。 3、写一个简明扼要的标题，并在正文描述清楚你的问题。 4、对于提供信息过少的问题，会直接关闭，请提供完整信息以后重新打开问题。 一、各位开发者，当审核未通过，请按如下模版反馈问题至工单或者社区发帖 1、小程序注册主体类型（企业、个人还是第三方）： 2、小程序账号（APPID、原始ID或者邮箱，三者之一即可）： 3、问题描述（具体问题介绍）： 4、问题截图（客户端问题界面截图）： 二、代码审核时间 登录微信公众平台小程序，进入开发管理，开发版本中展示已上传的代码，管理员可提交审核或是删除代码，代码审核7个工作日完成。 注：常规审核时间为2-3个工作日完成，如无特殊情况且未超过7个工作日发帖将不予反馈，请耐心等待审核结果。 三、小程序未通过会涉及哪些类型？ 主要涉及有小程序服务类目、基础信息、上线后功能使用、内容、可用性和完整性。 注意事项服务类目小程序发布的内容与小程序申请的服务类目要保持一致。 小程序发布的内容涉及特殊行业时，未选择相应的类目。特殊行业参考：特殊行业所需资质材料 小程序内容小程序内容不得发布平台支持的服务类目以外的内容：如游戏、虚拟支付等; 不得发布非法博彩，违反相关法律法规的内容。基础信息logo不得侵犯其他品牌权利； 详细小程序简介避免政治敏感、色情、敏感词语的出现; 不得对知名品牌名称添加特殊符号，恶意引导用户。小程序上线后功能使用小程序所实际提供的服务和内容，必须是正式的，不能以Demo形式提交; 不得以使用其他应用程序为条件使用小程序。可用性和完整性ios和安卓系统环境下，小程序首页都无法加载或者一直处于加载状态中。

官方表示 《目前长期性订阅消息仅向政务民生、医疗、交通、金融、教育等线下公共服务开放，后期将逐步支持到其他线下公共服务业务》 但是这些只是写出了一级类目， 实际上有些一级类目符合了， 二级类目也没有长期订阅消息模板，也没添加的入口， 这不是坑人吗？ 而且一个月只能修改三次服务类目， 希望官方能详细列出目前所符合的二级类目，供开发者参考，不然多浪费时间。

会话密钥session_key有效性开发者如果遇到因为session_key不正确而校验签名失败或解密失败，请关注下面几个与session_key有关的注意事项。 wx.login()调用时，用户的session_key会被更新而致使旧session_key失效。开发者应该在明确需要重新登录时才调用wx.login()，及时通过登录凭证校验接口更新服务器存储的session_key。 微信不会把session_key的有效期告知开发者。我们会根据用户使用小程序的行为对session_key进行续期。用户越频繁使用小程序，session_key有效期越长。 根据文档知道，每次wx:login()之后都会更新session-key,又有： [代码]wx.checkSession({  success: function(){    //session_key 未过期，并且在本生命周期一直有效[代码] [代码]      [代码] [代码]wx:[代码]DecryptParentInfo(......);   //解密用户信息 [代码]  },  fail: function(){    // session_key 已经失效，需要重新执行登录流程    wx.login() //重新登录    ....  } })[代码]现在想知道的是，界面用户信息时，需要用到session_key去解密iv、encryptedData，对此，同一小程序不同的用户都用session_key去解密iv、encryptedData时，每一个用户的session_key是否一致，说白了就是解密时，这个session_key是否所有用户都是共用的。。？？？？？还是说每一个用户解密时，都是不同的session_key（各自用各自的session_key）？？？？？？ 因为，出现了两个问题： 1）如果共用session_key的话，是否会出现一个问题：一个用户wx:checkSession()时没有过期，再去解密用户信息，而另一个用户刚好在解密之前再去登录刷新了session_key，此时session_key已改变，此时第一个用户解密将会失败，导致无法解密。。。。 2）如果不共用session_key的话，wx:checkSession()没过期后再用session_key在后台执行解密方法，大部分都是解密成功，偶尔出现了解密失败的情况，请问一下此时是什么问题导致的解密失败的。。。。。？？？？？？因为，发现一个问题就是并发去登录时，将会频繁出现解密用户信息失败，求大神帮忙感激不尽。。。。。。。。。。。。。。 最后想明确两个问题： 1）session_key是否解密时共用的（同一个session_key去解密不同的用户信息）？ 2）解密失败的根本原因？？？？？？？？

背景 我们发现大部分小程序都会使用 [代码]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[代码] 有效期是三天，所以建议开发者设置的登录态有效期要小于这个值。

官方说明授权窗口必须由button按钮引发。但最近体验一款小程序时，居然进入就能直接授权？ 以下截自官方文档 [图片] 本人体验的小程序叫【xiaopiu原型设计平台】 [图片]