背景
小程序一個比較重要的能力就是獲取用戶信息，也就是使用 wx.getUserInfo
接口。我們發(fā)現(xiàn)幾乎所有的小程序都會調(diào)用這個接口。雖然我們在設(shè)計文檔上有提出最好的設(shè)計是在真正要用戶信息的情況下才去獲取用戶信息，不過很多開發(fā)者并沒有按照我們的期望去做，導(dǎo)致用戶在使用的時候有很多困擾。
歸結(jié)起來有幾點：
開發(fā)者在首頁直接調(diào)用 wx.getUserInfo
進行授權(quán)，彈框有會使得一部分用戶放棄小程序的使用。
開發(fā)者沒有處理用戶拒絕彈框的情況，有部分小程序強制要求用戶授權(quán)頭像昵稱等信息才能繼續(xù)使用小程序。
用戶沒有很好的方式重新授權(quán)，雖然在前幾個版本我們增加了設(shè)置
頁面可以讓用戶選擇重新授權(quán)，但是操作還是不夠便捷。
開發(fā)者希望進到首頁就獲取到用戶的unionId
，以便和之前已經(jīng)關(guān)注了公眾號的用戶畫像關(guān)聯(lián)起來。
開發(fā)者默認將 wx.login
和 wx.getUserInfo
綁定使用，這個是由于我們一開始的設(shè)計缺陷和實例代碼導(dǎo)致： getUserInfo
必須通過wx.login
在后臺生成session_key
后才能調(diào)用。
為了解決以上幾點，我們更新了三個能力：
使用組件來獲取用戶信息，用戶拒絕授權(quán)后也可以重新彈窗再次授權(quán)
若用戶滿足一定條件(下文有詳細介紹)，則可以用wx.login
獲取到的code直接換到unionId
wx.getUserInfo
不依賴 wx.login
就能調(diào)用得到數(shù)據(jù)。
獲取用戶信息組件介紹
組件變化：
open-type
屬性增加 getUserInfo
：用戶點擊時候會觸發(fā) bindgetuserinfo
事件。
新增事件 bindgetuserinfo
：當 open-type
為 getUserInfo
時，用戶點擊會觸發(fā)。可以從事件返回參數(shù)的detail
字段中獲取到和wx.getUserInfo
返回參數(shù)相同的數(shù)據(jù)。
示例：
<button open-type="getUserInfo" bindgetuserinfo="userInfoHandler"> Click me </button>
和 wx.getUserInfo
不同之處在于：
API wx.getUserInfo
只會彈一次框，用戶拒絕授權(quán)之后，再次調(diào)用將不會彈框
組件
由于是用戶主動觸發(fā)，不受彈框次數(shù)限制，只要用戶沒有授權(quán)，都會再次彈框
直接獲取unionId
考慮很多場景下，業(yè)務(wù)方申請userinfo授權(quán)主要為了獲取unionid。我們鼓勵開發(fā)者在不騷擾用戶的情況下合理獲得unionid，而僅在必要時才向用戶彈窗申請使用昵稱頭像。為此，凡使用“獲取用戶信息組件”獲取用戶昵稱頭像的小程序，在滿足以下全部條件時，將可以靜默獲得unionid。
在微信開放平臺下存在同主體的App、公眾號、小程序。
用戶關(guān)注了某個相同主體公眾號，或曾經(jīng)在某個相同主體App、公眾號上進行過微信登錄授權(quán)。
getUserInfo 和 login
很多開發(fā)者會把login和getUserInfo捆綁調(diào)用當成登錄使用，其實login已經(jīng)可以完成登錄，可以建立賬號體系了，getUserInfo只是獲取額外的用戶信息。
在login獲取到code，然后發(fā)送到開發(fā)者后端，開發(fā)者后端再通過接口去微信后端換取到openid和sessionKey（并且現(xiàn)在會將unionid也一并返回）之后，然后把3rd_session返回給前端，就已經(jīng)完成登錄行為。而login行為是靜默，不必授權(quán)的，不會對用戶造成騷擾。
getUserInfo只是為了提供更優(yōu)質(zhì)的服務(wù)而存在，比如展示頭像昵稱，判斷性別，通過unionId和其他公眾號上已有的用戶畫像結(jié)合起來提供歷史數(shù)據(jù)。所以不必在剛剛進入小程序的時候就強制要求授權(quán)。
推薦使用方法
調(diào)用wx.login
獲取code
，然后從微信后端換取到sessionKey
，用于解密getUserInfo
返回的敏感數(shù)據(jù)。
使用wx.getSetting
獲取用戶的授權(quán)情況
如果用戶已經(jīng)授權(quán)，直接調(diào)用 API wx.getUserInfo
獲取用戶最新的信息
用戶未授權(quán)，在界面中顯示一個按鈕提示用戶登入，當用戶點擊并授權(quán)后就獲取到用戶的最新信息。
獲取到用戶數(shù)據(jù)后可以進行展示或者發(fā)送給自己的后端。
文檔中的quickStart已經(jīng)更新
特別注意
為了給用戶提供更好的小程序環(huán)境，我們約定在一段時間后（具體時間會做通知），若還出現(xiàn)以下情況（包括但不限于），將無法通過審核
初次打開小程序就彈框授權(quán)用戶信息
未處理用戶拒絕授權(quán)的情況
強制要求用戶授權(quán)
已經(jīng)上線的小程序不會受到影響。
FAQ
Q: 除了 UserInfo 呢，比如說位置信息 --- ’風(fēng)の諾言 .
A: 其他授權(quán)信息不像用戶信息那么高頻繁，也基本是在使用時候才申請授權(quán)，所以沒有同 UserInfo 一起給出。我們會先看看 UserInfo 的使用情況再結(jié)合具體場景我們會給出相應(yīng)的方案
Q: 后臺要維護用戶信息 --- Azleal
我們的小程序業(yè)務(wù)是功能都需要授權(quán)才能使用的(也就是必須拿到unionid獲取用戶信息) --- elemeNT
我在小程序與服務(wù)號的數(shù)據(jù)需要互通，通過unionId來確定用戶的唯一性，如果在用戶進入小程序后不強制他授權(quán)，單憑一個openid來存儲他的用戶數(shù)據(jù)，在用戶下次從服務(wù)號進入時。不就會產(chǎn)生重復(fù)數(shù)據(jù)嗎？就沒做到數(shù)據(jù)互通了 --- ?并向你吐了趴口水?五年.
另外看到官方提到 要強制推行，我想說我們目前所有用戶是通過unionid注冊的。那么這些用戶就不得不使用 openid重新登錄 、注冊一遍。更重要的是，之前他們的相關(guān)數(shù)據(jù)都會對應(yīng)不上（因為你們也不允許強制用戶登錄授權(quán)） --- 羊毛
現(xiàn)在這種方案，不能滿足我們的需求，我們的小程序，必須一進入就要獲取他的信息，然后加載他的數(shù)據(jù)； --- 韓文
A: 調(diào)用wx.login已經(jīng)可以獲取到用戶的登錄態(tài)，已經(jīng)可以做用戶賬號的管理。 UserInfo 中帶的 UnionId 是額外的信息，沒有它完全可以完成登錄
對于需要和開發(fā)平臺綁定的業(yè)務(wù)進行數(shù)據(jù)互通的情況，一個新用戶進來沒有互通數(shù)據(jù)的情況下也是可以體驗到所有業(yè)務(wù)，那么對于沒有授權(quán)unionId的用戶，可以將其當成是新用戶，當真正授權(quán)unionId之后再做綁定完全是可以的
Q: 我需要確保用戶的唯一性，這樣就必須取unionID，否則用戶刪除了小程序，或者換了設(shè)備， 下次再進來這個小程序，該用什么來區(qū)分是上次來過的用戶呢？？ --- WEI+
A: 如果你本身沒有其他公眾號、App、小程序，那么也就沒必要拿到unionid，因為unionid是打通你在開放平臺下所有應(yīng)用的標識
如果只有一個小程序，用 openid 足以， openid 是一個用戶對于一個小程序的標識，永遠不變
Q: wx.getUserInfo 是網(wǎng)絡(luò)請求，如果使用了 open-type = "getUserInfo"，是否每次點擊都會調(diào)接口？ --- SouthernBox
A: 是的，open-type="getUserInfo" 的作用以及內(nèi)部實現(xiàn)基本和 wx.getUserInfo 一樣
區(qū)別是一個開發(fā)者主動（拒絕一次不再彈窗），一個是用戶主動（拒絕任意次都可以重新彈窗）
Q: 比如有一個創(chuàng)建按鈕，用戶點擊一次授權(quán)了，我已經(jīng)獲取到用戶信息，再次點擊就沒必要再調(diào)用 getUserInfo 去網(wǎng)絡(luò)請求了。 --- SouthernBox
A: 可以參考文中 quickStart 的做法，如果已經(jīng)授權(quán)了，那就可以把按鈕隱藏，之后的授權(quán)直接用API wx.getUserInfo 調(diào)用（因為已經(jīng)授權(quán)，所以也不會彈窗），用戶也不會再點了
Q: 小程序是不是必須要用微信自帶的授權(quán)才可以登錄 ，能否不使用授權(quán)方式登錄，用自己系統(tǒng)的api接口數(shù)據(jù)實現(xiàn)？這個會不會涉及到審核不過的問題？？麻煩解答一下 謝謝了。 --- WEI+
A: 自己做登錄不會涉及到審核問題。
不過不建議在沒有原有賬號體系的情況下讓用戶在小程序內(nèi)注冊，過重的行為會損失用戶。
Q: 在小程序中有一個"我的"頁面，這是屬于會員頁，如果用戶要進入這個頁面就必須授權(quán)。交互方式就是在用戶未授權(quán)情況下整個頁面只顯示一個授權(quán)獲取用戶信息的button 按鈕，這個需要用戶自己去觸發(fā)，算不算強制授權(quán)？ --- ?并向你吐了趴口水?五年.
A: 強制授權(quán)是說如果用戶如果不授權(quán)基本信息，連最基礎(chǔ)的瀏覽功能都不提供（當然這個也是要分具體的業(yè)務(wù)場景，不會限制得太死板）
可以有更好的交互，參考下主流App，在未登錄的時候點擊【我的】頁面，也不會直接要求登錄，而是展示了一定的頁面結(jié)構(gòu)，同時給一個登錄按鈕（例如【攜程】【京東】等），之后再在這個頁面做操作的話可以彈一個登錄頁面或按鈕提示用戶登錄是完全可以的。
上述所說的登錄只是用戶感知上的登錄，從業(yè)務(wù)邏輯上用戶其實在 wx.login 的時候已經(jīng)完成登錄了。
Q: 看了很多評論，有些人還是不知道為什么官方要這樣做，我作為一個商家角度來說下。 --- Mr.J
比如我們要做一些戶外推廣的二唯碼，用戶只看到了你的圖片宣傳單，掃描二唯碼一打開就提示“需要獲取你的個人信息，您是否允許”，你不要當自己是開發(fā)者當自己是一個正常人，看到這個提示我相信很多人的第一反應(yīng)就是拒絕。如果第一步已經(jīng)把你拒之門外，談何營銷？
沒有小程序之前，我們在公眾號有很多用戶，都綁定了unionid，有小程序之后我們考慮怎么讓用戶接受小程序，可以靜默登錄我覺得非常好，從公眾號過來的用戶可以直接就登錄了，沒有任何提示，完美的對接，這是一個很好的體驗。
A: 說得很好，我們的這些改造不僅是為了開發(fā)者，同時也是為了這個生態(tài)下的用戶考慮。希望開發(fā)者們也能站在用戶的角度去思考怎么做一個產(chǎn)品。
Q: 我不明白為什么login 給多個unionid 為什么不行？ unionid也不能算是個人信息吧，給多個unionid可以更方便開發(fā)者，而且很多情況下就不用調(diào)用getUserInfo了 --- candyTong
我們提個建議，能否直接開放unionid呢？這樣也許會有許多小程序不需要再彈窗了。既一定程度保障了用戶體驗，也照顧到了我們開發(fā)者的體驗。 --- 羊毛
A: 如果直接開放了unionid，就會出現(xiàn)這種情況：當你作為一個用戶進入一個小程序，這個小程序并沒要求你授權(quán)就直接把你的頭像昵稱顯示出來（它之前把unionId對應(yīng)的頭像昵稱都存了下來），但是這個小程序主體（open平臺主體和公眾平臺主體并不相同）相關(guān)的任何一個應(yīng)用你從來沒用過，你會不會覺得很奇怪并且很不舒服，覺得自己在微信內(nèi)的用戶信息沒有絲毫的保障？
Q: 那有推薦的比較好的例子么？對于必須使用用戶頭像、昵稱這些信息的小程序而言 --- 亞里士朱德
A: 首先，沒有什么邏輯是一定要使用用戶的頭像、昵稱才能work的。對于這個case，完全可以先用默認頭像、匿名昵稱先做替代，用戶點擊默認頭像后就可以彈出授權(quán)信息，非常的水到渠成。
Q: 之前看了這個帖子一直在思考，如果是一進去需要回去用戶的地理位置信息顯示到地圖上的呢？這樣算不算是一進去就彈窗授權(quán)獲取用戶信息？ --- 吳俊績??
A: 地圖的情況和獲取用戶信息不同，我們目前還沒對地圖的授權(quán)請求有所調(diào)整。當前不受上述策略的影響
Q: 對于開發(fā)者而言，小程序與公眾號是同級的，只是不同的入口 但是這樣的設(shè)計，公眾號與小程序成了主從關(guān)系咯 --- log琥珀①
A: 并無什么主從關(guān)系，只是多一個渠道讓開發(fā)者可以更方便的獲取到已經(jīng)是該主體下用戶的unionId
