场景

最近公司让我开始维护一个微信小程序的应用，由于第一次接触小程序，对小程序一知半解的我开始了趟坑。
业务中有这么一个场景，我们使用微信的扫描二维码来进入小程序支付费用。走的流程如下：

扫描 - auth验证页操作(包括授权，关注公众号，绑定手机) - pay支付页操作

而且验证页面是半自动的。从获取微信用户数据，轮训关注信息，判断用户需要进行哪一步这些，手机绑定操作，这一系列都做完之后会自动地跳转到支付页面。

产品给出一个需求，需要再支付页操作的时候，可以在左上角返回到首页。

就此开始掉入深渊慢慢往上爬。

navigateTo和redirectTo

由于此项目之前的代码是用redirectTo来跳转支付页面。而且auth验证页面又是扫码进入小程序的第一个页面。redirectTo在跳转之前会销毁页面再进行跳转。就会在小程序的页面栈中将auth页面销毁，销毁之后，pay页面就是唯一在页面栈中的页面。于是根据小程序的规则，此种情况下左上角是不会出现返回按钮的。现在我们进行更改。
将auth跳转pay的方式改为navigateTo,如下:

wx.navigateTo({
  url:"../pay/index"
});

在此之后，我们就会在pay页面的左上角看到返回按钮了。

尝试点击返回按钮。

我们在pay页面尝试点击返回按钮，在这之后，我们会看到我们又进入了auth页面。并且，因为我们在第一次进入的时候，已经授权过用户信息，关注了公众号，绑定了手机。导致我们直接通过了其验证，马上又跳转到了pay页面。如此往复，点击，跳转，点击，跳转。形成了死循环。这当然不对，产品经理说的是返回首页。
那现在我们来看看怎么返回首页。

先前的做法，返回首页方式。

这个项目之前也有返回首页的需求。在非扫码情况下进入小程序，会默认进入首页。然后一步一步地进入想要去到的各种业务界面。当时的方案如下：
1.进入首页之后，跳转到下一个页面的时候全部用navigateTo进行跳转。
2.之后的二级页面和更下级页面之后的所有跳转都用redirectTo进行跳转。
这样，我们就发现，页面的栈里面就只会有首页。不管你在哪个页面只要点击了左上角的返回按钮，就会跳转到首页。但是这种情况只能是我们先进入首页的情况，必须在第一时间就已经将首页加入到了页面的栈中,而我们这个业务场景首先进入的是auth页，全程没看到过首页index出现在任何一个业务逻辑点。于是这种方法行不通。

现在的做法

经过深思熟虑，上面的方法是没办法达成的，必须另辟蹊径。
我在auth页面跳转pay页面的时候，首先运用navigateTo来跳转，pay页面就会出现左上角的返回按钮。此时，页面栈中油2个页面的信息，分别是auth和pay。
点击返回按钮之后，我们回到auth页面，页面栈中pay弹出，只剩auth。此时，我们在onShow顶部加入了一段代码。

const pages = getCurrentPages();
const prePage = pages[pages.length - 1].__displayReporter.showReferpagepath;
if(prePage === "pages/scan_pay/index.html"){
      wx.reLaunch({
        url:"../index/index"
      });
      return
    }

我们通过getCurrentPages来获取到页面的执行栈，这里获取到auth。
并且在这个页面栈数组中，只有auth。我们取到auth.__displayReporter.showReferpagepath。
这个就是上一页的路径，也就是返回到auth之前的pay页面。

我们进行判断。然后就可以直接回到首页了。

只不过这样有一个缺点，就是返回index页面之前要短暂地显示一下auth页。
综合各个大公司遇到的类似场景：例如美团外卖小程序在绑定用户信息的时候也会跨页面返回。也会短暂地显示中间的过渡页面。目前应该找不到更有效的方法了。

比巨坑还大的石油坑：
今天2019.5.9日。扫码进入微信小程序(场景值1011)的环境下，调不出关注公众号组件，会在official-account的binderror绑定的函数中返回这样的信息：

image.png

不得不感慨腾讯公司你们真的不要这样搞啊，给我们用了后面又抽风，会把我们惯坏的，很多小程序都要因为这个特性没有而彻底重构了。
NM$L