背景html
小程序一个比较重要的能力就是获取用户信息，也就是使用 wx.getUserInfo 接口。咱们发现几乎全部的小程序都会调用这个接口。虽然咱们在设计文档上有提出最好的设计是在真正要用户信息的状况下才去获取用户信息，不过不少开发者并无按照咱们的指望去作，致使用户在使用的时候有不少困扰。前端
归结起来有几点：小程序
-
开发者在首页直接调用
wx.getUserInfo进行受权，弹框有会使得一部分用户放弃小程序的使用。后端 -
开发者没有处理用户拒绝弹框的状况，有部分小程序强制要求用户受权头像昵称等信息才能继续使用小程序。api
-
用户没有很好的方式从新受权，虽然在前几个版本咱们增长了
设置页面可让用户选择从新受权，可是操做仍是不够便捷。微信 -
开发者但愿进到首页就获取到用户的
unionId，以便和以前已经关注了公众号的用户画像关联起来。网络 -
开发者默认将
wx.login和wx.getUserInfo绑定使用，这个是因为咱们一开始的设计缺陷和实例代码致使：getUserInfo必须经过wx.login在后台生成session_key后才能调用。session
为了解决以上几点，咱们更新了三个能力：框架
-
使用组件来获取用户信息，用户拒绝受权后也能够从新弹窗再次受权post
-
若用户知足必定条件(下文有详细介绍)，则能够用
wx.login获取到的code直接换到unionId -
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 不一样之处在于：
-
API
wx.getUserInfo只会弹一次框，用户拒绝受权以后，再次调用将不会弹框 -
组件
因为是用户主动触发，不受弹框次数限制，只要用户没有受权，都会再次弹框
直接获取unionId
考虑不少场景下，业务方申请userinfo受权主要为了获取unionid。咱们鼓励开发者在不骚扰用户的状况下合理得到unionid，而仅在必要时才向用户弹窗申请使用昵称头像。为此，凡使用“获取用户信息组件”获取用户昵称头像的小程序，在知足如下所有条件时，将能够静默得到unionid。
-
在微信开放平台下存在同主体的App、公众号、小程序。
-
用户关注了某个相同主体公众号，或曾经在某个相同主体App、公众号上进行过微信登陆受权。
getUserInfo 和 login
不少开发者会把login和getUserInfo捆绑调用当成登陆使用，其实login已经能够完成登陆，能够创建帐号体系了，getUserInfo只是获取额外的用户信息。
在login获取到code，而后发送到开发者后端，开发者后端再经过接口去微信后端换取到openid和sessionKey（而且如今会将unionid也一并返回）以后，而后把3rd_session返回给前端，就已经完成登陆行为。而login行为是静默，没必要受权的，不会对用户形成骚扰。
getUserInfo只是为了提供更优质的服务而存在，好比展现头像昵称，判断性别，经过unionId和其余公众号上已有的用户画像结合起来提供历史数据。因此没必要在刚刚进入小程序的时候就强制要求受权。
推荐使用方法
-
调用
wx.login获取code，而后从微信后端换取到sessionKey，用于解密getUserInfo返回的敏感数据。 -
使用
wx.getSetting获取用户的受权状况 -
若是用户已经受权，直接调用 API
wx.getUserInfo获取用户最新的信息 -
用户未受权，在界面中显示一个按钮提示用户登入，当用户点击并受权后就获取到用户的最新信息。
-
获取到用户数据后能够进行展现或者发送给本身的后端。
文档中的quickStart已经更新
特别注意
为了给用户提供更好的小程序环境，咱们约定在一段时间后（具体时间会作通知），若还出现如下状况（包括但不限于），将没法经过审核
-
初次打开小程序就弹框受权用户信息
-
未处理用户拒绝受权的状况
-
强制要求用户受权
已经上线的小程序不会受到影响。
FAQ
Q: 除了 UserInfo 呢，好比说位置信息 --- ’风の诺言 .
A: 其余受权信息不像用户信息那么高频繁，也基本是在使用时候才申请受权，因此没有同 UserInfo 一块儿给出。咱们会先看看 UserInfo 的使用状况再结合具体场景咱们会给出相应的方案
Q: 后台要维护用户信息 --- Azleal
咱们的小程序业务是功能都须要受权才能使用的(也就是必须拿到unionid获取用户信息) --- elemeNT
我在小程序与服务号的数据须要互通，经过unionId来肯定用户的惟一性，若是在用户进入小程序后不强制他受权，单凭一个openid来存储他的用户数据，在用户下次从服务号进入时。不就会产生重复数据吗？就没作到数据互通了 --- ﺭ并向你吐了趴口水ﺭ五年.
另外看到官方提到 要强制推行，我想说咱们目前全部用户是经过unionid注册的。那么这些用户就不得不使用 openid从新登陆 、注册一遍。更重要的是，以前他们的相关数据都会对应不上（由于大家也不容许强制用户登陆受权） --- 羊毛
如今这种方案，不能知足咱们的需求，咱们的小程序，必须一进入就要获取他的信息，而后加载他的数据； --- 韩文
A: 调用`wx.login`已经能够获取到用户的登陆态，已经能够作用户帐号的管理。 UserInfo 中带的 UnionId 是额外的信息，没有它彻底能够完成登陆
对于须要和开发平台绑定的业务进行数据互通的状况，一个新用户进来没有互通数据的状况下也是能够体验到全部业务，那么对于没有受权unionId的用户，能够将其当成是新用户，当真正受权unionId以后再作绑定彻底是能够的
Q: 我须要确保用户的惟一性，这样就必须取unionID，不然用户删除了小程序，或者换了设备， 下次再进来这个小程序，该用什么来区分是上次来过的用户呢？？ --- WEI+
A: 若是你自己没有其余公众号、App、小程序，那么也就不必拿到unionid，由于unionid是打通你在开放平台下全部应用的标识
若是只有一个小程序，用 openid 足以， openid 是一个用户对于一个小程序的标识，永远不变
Q: wx.getUserInfo 是网络请求，若是使用了 open-type = "getUserInfo"，是否每次点击都会调接口？ --- SouthernBox
A: 是的，open-type="getUserInfo" 的做用以及内部实现基本和 wx.getUserInfo 同样
区别是一个开发者主动（拒绝一次再也不弹窗），一个是用户主动（拒绝任意次均可以从新弹窗）
Q: 好比有一个建立按钮，用户点击一次受权了，我已经获取到用户信息，再次点击就不必再调用 getUserInfo 去网络请求了。 --- SouthernBox
A: 能够参考文中 quickStart 的作法，若是已经受权了，那就能够把按钮隐藏，以后的受权直接用API wx.getUserInfo 调用（由于已经受权，因此也不会弹窗），用户也不会再点了
Q: 小程序是否是必需要用微信自带的受权才能够登陆 ，可否不使用受权方式登陆，用本身系统的api接口数据实现？这个会不会涉及到审核不过的问题？？麻烦解答一下 谢谢了。 --- WEI+
A: 本身作登陆不会涉及到审核问题。
不过不建议在没有原有帐号体系的状况下让用户在小程序内注册，太重的行为会损失用户。
Q: 在小程序中有一个"个人"页面，这是属于会员页，若是用户要进入这个页面就必须受权。交互方式就是在用户未受权状况下整个页面只显示一个受权获取用户信息的button 按钮，这个须要用户本身去触发，算不算强制受权？ --- ﺭ并向你吐了趴口水ﺭ五年.
A: 强制受权是说若是用户若是不受权基本信息，连最基础的浏览功能都不提供（固然这个也是要分具体的业务场景，不会限制得太死板）
能够有更好的交互，参考下主流App，在未登陆的时候点击【个人】页面，也不会直接要求登陆，而是展现了必定的页面结构，同时给一个登陆按钮（例如【携程】【京东】等），以后再在这个页面作操做的话能够弹一个登陆页面或按钮提示用户登陆是彻底能够的。
上述所说的登陆只是用户感知上的登陆，从业务逻辑上用户其实在 wx.login 的时候已经完成登陆了。
Q: 看了不少评论，有些人仍是不知道为何官方要这样作，我做为一个商家角度来讲下。 --- Mr.J
1. 好比咱们要作一些户外推广的二惟码，用户只看到了你的图片宣传单，扫描二惟码一打开就提示“须要获取你的我的信息，您是否容许”，你不要当本身是开发者当本身是一个正常人，看到这个提示我相信不少人的第一反应就是拒绝。若是第一步已经把你拒之门外，谈何营销？
2. 没有小程序以前，咱们在公众号有不少用户，都绑定了unionid，有小程序以后咱们考虑怎么让用户接受小程序，能够静默登陆我以为很是好，从公众号过来的用户能够直接就登陆了，没有任何提示，完美的对接，这是一个很好的体验。
A: 说得很好，咱们的这些改造不只是为了开发者，同时也是为了这个生态下的用户考虑。但愿开发者们也能站在用户的角度去思考怎么作一个产品。
Q: 我不明白为何login 给多个unionid 为何不行？ unionid也不能算是我的信息吧，给多个unionid能够更方便开发者，并且不少状况下就不用调用getUserInfo了 --- candyTong
咱们提个建议，可否直接开放unionid呢？这样也许会有许多小程序不须要再弹窗了。既必定程度保障了用户体验，也照顾到了咱们开发者的体验。 --- 羊毛
A: 若是直接开放了unionid，就会出现这种状况：当你做为一个用户进入一个小程序，这个小程序并没要求你受权就直接把你的头像昵称显示出来（它以前把unionId对应的头像昵称都存了下来），可是这个小程序主体（open平台主体和公众平台主体并不相同）相关的任何一个应用你历来没用过，你会不会以为很奇怪而且很不舒服，以为本身在微信内的用户信息没有丝毫的保障？
Q: 那有推荐的比较好的例子么？对于必须使用用户头像、昵称这些信息的小程序而言 --- 亚里士朱德
A: 首先，没有什么逻辑是必定要使用用户的头像、昵称才能work的。对于这个case，彻底能够先用默认头像、匿名昵称先作替代，用户点击默认头像后就能够弹出受权信息，很是的水到渠成。
Q: 以前看了这个帖子一直在思考，若是是一进去须要回去用户的地理位置信息显示到地图上的呢？这样算不算是一进去就弹窗受权获取用户信息？ --- 吴俊绩🤔
A: 地图的状况和获取用户信息不一样，咱们目前还没对地图的受权请求有所调整。当前不受上述策略的影响
Q: 对于开发者而言，小程序与公众号是同级的，只是不一样的入口 可是这样的设计，公众号与小程序成了主从关系咯 --- log琥珀①
A: 并没有什么主从关系，只是多一个渠道让开发者能够更方便的获取到已是该主体下用户的unionId