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

原因：

微信側(cè)掃碼啟動參數(shù)錯亂。

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

解決方案：

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

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

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

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

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

問題雖小，記錄意義更大。

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

也歡迎一起貢獻倉庫： 小程序bug集合