刚提交了审核通过的版本，扫码发布，还是原来的版本。
之前有发不过一个小程序版本，现在更新了一个小程序版本后发布，提交后大概审核了10个小时左右，审核通过，通过后进行了全量发布，发布完30分钟以内扫码或者直接通过之前的入口进入小程序，都显示之前的版本。
在大约30分钟左右的时间，再次进入小程序发现才是已经更新后的版本。
我更新版本后的小程序
以下是小程序官方给的说明，大家可以参考：
背景
此前有开发者反馈小程序发布新版本后，新版本覆盖率比较慢，因为小程序的更新机制是异步的，部分用户不会马上应用上新版本。
小程序启动会有两种情况，一种是「冷启动」，一种是「热启动」。 假如用户已经打开过某小程序，然后在一定时间内再次打开该小程序，此时无需重新启动，只需将后台态的小程序切换到前台，这个过程就是热启动；冷启动指的是用户*次打开或小程序被微信主动销毁后再次打开的情况，此时小程序需要重新加载启动。
小程序的异步更新发生在冷启动过程，当发现新版本后，会异步下载新版本的代码包，但不会马上应用上*新版本，需要等小程序下*冷启动，才会应用上新版本。
解决思路
为了解决这个问题，我们内部也经历了数个方案的讨论，这里简单介绍下：
1. 同步检查更新（放弃）：可能是*直接的解决思路，但主要问题是会影响小程序的启动速度，当下小程序的更新迭代是非常频繁的，部分用户可能每次启动都命中更新，如果需要同步检查更新+同步下载新的版本，那将会影响这部分用户的启动体验。
2. 模块热替换（放弃）：从技术上来说，这是*好的方案，小程序运行起来后，在打开新页面时，马上应用新版本里的页面，但这就会存在新旧逻辑、页面共存问题，对于开发者来说，反而更不好处理，特别是涉及到全局变量时，情况会更复杂，对于我们已有的框架来说，也是一个大挑战，不过这个也是我们之后努力的方向。
3. 定时 check 新版本（目前方案）：6.6.3 及以上版本的客户端，会定时 check *近使用过的小程序是否有发布新版本；如果有，下次打开的时候会同步更新新版本再打开。这可以保证在新版本发布 24 小时后，所有小程序都能使用*新版本。（这部分是微信客户端自身优化，开发者无需关心）
4. 异步更新 + 强制更新（目前方案）：同步检查更新与模块热替换两者之间的折衷方案，即还是维持异步更新机制，在异步下载完小程序代码包后，提供重启小程序的能力，这样在遇到紧急问题时可以马上解决。
