作者介紹：
陳小二，現新美大高階前端渣渣、弱勢群體（小程式開發者）抱團取暖組織成員之一。平時喜歡玩遊戲（最近迷戀吃雞）+養貓。寫這段廢話的目的其實是：我們正在等待第三位愛好寫作的小夥伴加入我們~然後一起灌水~
問題：
使用者掃碼二維碼A，小程式onload中傳遞q引數為二維碼地址B，且該二維碼地址為使用者歷史使用二維碼地址。
原因：
微信側掃碼啟動引數錯亂。
使用者使用微信“掃一掃”掃描二維碼A，微信通過系統事件啟動小程式，使用者使用完之後，
將小程式退到後臺，一段時間後小程式被系統回收。使用者再次掃描二維碼B，
微信仍然通過系統事件啟動小程式，但是實際上，系統先發出A二維碼的啟動事件，
再發出B二維碼的啟動事件，導致小程式啟動引數錯亂。
理論上，使用者第二次掃碼的時候，系統不應該連續發出兩次事件。
複製程式碼解決方案：
方案1 :
微信側目前上線了熱修復方案，解決該問題，保證通過系統事件啟動時傳遞正確的碼地址。但目前該方案僅能覆蓋最近兩個版本，即6.5.20以後的，覆蓋人群不會很高，活躍使用者的七八成所以對於剩下的2-3成使用者，仍然存在該問題。
方案2 ：
方案2會解決剩下的2-3成活躍使用者。
目前掃碼啟動小程式的場景，微信會將原始URL通過引數的方式傳給小程式，key為”q”。
後臺改動上線後，會多出一個key為”scancode_time”的UNIX時間戳引數，是使用者掃碼的時間。
使用者掃碼時間和執行onlaod的時間相對比如果在30s以內，可以認為傳遞給我們的碼地址是30s以內剛掃過的碼，可以認為傳遞的非歷史地址。從這個邏輯出發，做了以下校驗：
ps: 第二次將掃碼時間與伺服器端時間再次進行校驗的目的：避免部分使用者手動更改手機時間
或者本地手機時間差距較大，導致問題出現，故再進行一次服務端時間校驗。
複製程式碼另外： 歡迎加入我們：
也歡迎和我們一起貢獻倉庫：小程式bug集合
詳細的可以瞅瞅微信小程式開發者經驗分享組織成立啦~~~