背景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