用戶(hù)掃碼二維碼A，小程序onload中傳遞q參數為二維碼地址B，且該二維碼地址為用戶(hù)歷史使用二維碼地址。

原因：

微信側掃碼啟動(dòng)參數錯亂。

用戶(hù)使用微信“掃一掃”掃描二維碼A，微信通過(guò)系統事件啟動(dòng)小程序，用戶(hù)使用完之后，
將小程序退到后臺，一段時(shí)間后小程序被系統回收。用戶(hù)再次掃描二維碼B，
微信仍然通過(guò)系統事件啟動(dòng)小程序，但是實(shí)際上，系統先發(fā)出A二維碼的啟動(dòng)事件，
再發(fā)出B二維碼的啟動(dòng)事件，導致小程序啟動(dòng)參數錯亂。
理論上，用戶(hù)第二次掃碼的時(shí)候，系統不應該連續發(fā)出兩次事件。

解決方案：

方案1 (覆蓋7-8成用戶(hù)):

微信側目前上線(xiàn)了熱修復方案，糾正該問(wèn)題，保證通過(guò)系統事件啟動(dòng)時(shí)傳遞正確的碼地址。但目前該方案僅能覆蓋最近兩個(gè)版本，即6.5.20以后的，覆蓋人群不會(huì )很高，活躍用戶(hù)的七八成。所以仍然存在該bug.

方案2 (解決剩下的2-3成用戶(hù))：

目前掃碼啟動(dòng)小程序的場(chǎng)景，微信會(huì )將原始URL通過(guò)參數的方式傳給小程序，key為"q"。 后臺改動(dòng)上線(xiàn)后，會(huì )多出一個(gè)key為"scancode_time"的UNIX時(shí)間戳參數，是用戶(hù)掃碼的時(shí)間。 用戶(hù)掃碼時(shí)間和執行onlaod的時(shí)間相對比如果在30s以?xún)?，可以認為傳遞給我們的碼地址是30s以?xún)葎倰哌^(guò)的碼，可以認為傳遞的非歷史地址。從這個(gè)邏輯出發(fā)，做了以下校驗：

ps:第二次將掃碼時(shí)間與服務(wù)器端時(shí)間再次進(jìn)行校驗的目的：避免部分用戶(hù)手動(dòng)更改手機時(shí)間或者本地手機時(shí)間差距較大，導致問(wèn)題出現，故再進(jìn)行一次服務(wù)端時(shí)間校驗。

問(wèn)題雖小，記錄意義更大。

另外：歡迎加入 弱勢群體（開(kāi)發(fā)小程序的前端工程師們）共享bug組織

也歡迎一起貢獻倉庫： 小程序bug集合）共享bug組織