正文
作者介绍：
陈小二，现新美大高级前端渣渣、弱势群体（小程序开发者）抱团取暖组织成员之一。平时喜欢玩游戏（最近迷恋吃鸡）+养猫。写这段废话的目的其实是：我们正在等待第三位爱好写作的小伙伴加入我们~然后一起灌水~
问题：
用户扫码二维码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组织
也欢迎和我们一起贡献仓库：小程序bug集合
详细的可以瞅瞅微信小程序开发者经验分享组织成立啦~~~
