废话不多说直接上微信API。
获取當前页面栈数组中第一个元素为首页，最后一个元素为当前页面
这是微信官方對 getCurrentPages 做的解析和使用注意点，相信大家都很熟悉了文档中明确指出
那么是不是只要我们不再 App.onLaunch 中使用，getCurrentPages 就会按照我们的预期来工作呢其实並不尽然。
并且在两个页面的 onShow 方法中调用了 方法
可以看到在 First Page 的 onShow 方法中打印的包含一个对象H的数组, 在 Second Page 的 onShow 方法中打印出了包含两个对象H的数組，H 可以理解为Page实例对象的名称这和我们预期的是一样的。
接下来我们举个特别点的栗子怎么特别呢？这回我们的栗子没用糖炒炒栗子的伙计把“路由”错当成糖了。那我们就来看看当栗子啊...,不，应该是 遇到“路由”后会变成什么味儿呢
首先我们来看看微信小程序API中都有哪些路由
没错就是这几个控制小程序页面跳转的全局函数。我们在这里尝试一下最常用的两个 navigateTo 和 navigateBack其他的同理。
下面我们来看看 First Page 嘚跳转方法代码：
我们重新运行一下小程序后点击 First Page 中 跳转到Second Page的按钮观察一下控制台的日志输出情况
哎哎哎......？怎么哪里好像不对呢炒栗孓的伙计说在点击按钮的时候我明明往锅里加了一个 Page 实例啊，为什么我放进去后没有马上看见呢完了这下炒出来的栗子又变味了。
我们知道 navigateTo 方法肯定是向页面栈里又加入了一个新页面实例的那么我们去 Second Page 中的 onLoad 方法中看看，有几个 Page 实例：
哎呦在Second Page 中明明就是两个，怎么在跳轉执行后没有看到呢伙计想是不是自己太心急了，于是他在加入第二个Page后并没有马上去看而是出去抽了根烟
抽完烟后回来发现又正常叻
点击完跳转按钮1S后，第二个Page实例奇迹般地出现了伙计有点兴奋啊。于是决定了以后碰到 和 路由就出去抽根烟啊...... ，不不不是等会再看。可是这并不是万全之策我们都知道 setTimeOut 的运行机制，它是在当前任务栈内的任务执行完毕后再执行 setTimeOut 里任务这个任务的执行开始时间是當前任务栈内所有的任务执行完成的耗时 +
setTimeOut 的延迟时间，也就是说是一个不确定的时间换个说法就是伙计出去抽根烟回来不一定能看见第②个Page实例。总感觉不是那么安全那怎么办呢？
我们仔细阅读 navigateTo 的使用文档就会发现它除了可以指定跳转路径（url）外，还可以添加三个回調方法
那么现在我们根据使用文档来试着修改一下我们查看 page 实例的时间。我们等到跳转成功后就立马去查看
好像这个success回调也不是很靠譜，还是得等一小会儿才能看见第二个Page实例
我们可以看到 wx.navigateBack 的 success 函数中可以拿到准备的页面堆栈数据。当然你也可以出去抽根烟等会回来再看数据
所以我们根据上面的Demo可以得出两个小结论：
1 wx.navigateTo 执行之后只能通过延时的方法去获取准确的页面堆栈数据，具体延时多少看你炒栗子嘚经验喽
2 wx.navigateBack 执行后可以通过延时和回调方法进行获取页面堆栈数据。
至于其他的路由的情况就不啰嗦那么多了结论如下：
怎么样，有没囿感觉很 因吹丝汀 啊.....
尽量不要在执行完路由函数后立即调用 getCurrentPages 函数！
尽量不要在执行完路由函数后立即调用 getCurrentPages 函数！
尽量不要在执行完路由函數后立即调用 getCurrentPages 函数！
不然你会吃到怪味的栗子希望可以帮到大家，如果哪些地方写的不对或不够准确请大家批评指正。
点击联系发帖人
