我们后端做了版本控制，每次大版本都会升级版本，一般会维护两个版本。
比如线上版本是 1.0.0 和 2.0.0， 我们要升级到3.0.0，准备就是所有小程序都升级到2.0.0版本，24小时后下掉后端的1.0.0版本，发布3.0.0版本。
按照微信的小程序更新机制，2.0.0版本发布24小时后，所有用户再次冷启动肯定会同步更新到2.0.0版本。
但是目前发现，即使所有小程序更新到了2.0.0版本，一个星期后还是有部分1.0.0版本的流量，用户无法正常使用。
这个1.0.0的流量大概有哪些原因。
这个版本检测的代码是有的。只是用户进来会因为版本问题先报错，然后通过版本检测执行强制更新操作，但是用户还是看到了报错的过程，以及在下载的新版本的时候用户可能就离开了。
即使报错，我们对首页数据做了缓存，用户即使忽略了报错信息，会点击操作，会发现更多的问题。
目前优化方案是，检测到更新的过程直接显示一个全局的更新状态，阻止用户操作，直到下载完成让用户重启。
主要是想优化这块流程，或者避免这种情况的发生。
这种原因基本都是用户在1.0版本的时候打开过你的小程序，然后就一直没有用；
当你把1.0版本下线后，3.0版本上线后，用户又重新打开了小程序，而且这个打开还不是通过搜索打开的，有可能是小程序消息或者历史小程序等途径。
这时候，小程序有一定概率不会提示升级，也不会默认启用2.0版的小程序。你可以分析下这些流量有什么共同点，比如机型、微信版本、打开途径等，然后根据实际情况做优化。
当然，如果接口能做到兼容就更好了，这个就要根据实际情况处理了。理论上，打开小程序就进行版本检测，应该问题不大，这个版本检测是共同接口，所有版本的小程序都有。然后首页数据做好控制就可以了。
版本向下兼容呗，
或者全局检测版本利用接口查询当前线上版本号，匹配才继续正常流程，不匹配就强制更新
基本无法避免。