如果你使用 Component 构造器构造页面，那你可以使用 behavior 来给所有页面施加一组统一的逻辑。

不过，路由控制逻辑应该在路由方法真正实施前执行，才具有比较好的体验。因而封装 wx.navigateTo 是更加合理的方法。

原则上我们在基础库内仅提供基础特性和对性能有价值的特性，不提供高层封装。

首先，路由跳转不仅仅是在component中，page也会有。Page构造器的功能明显弱于Component构造器。但Page构造器是不能省略的，毕竟小程序无法实现SPA页面应用。小程序的路由体系决定了必须要使用多页面应用。因此behavior功能在Page构造器中无能为力。

其次，没有要拦截并抑制路由跳转的意图。我所做的事情也是要封装wx.navigateTo等方法达到小程序基础库没有提供的更友好的API。没有要求小程序提供高层封装，只是希望暴露更多的基础接口出来，比如，路由变化的事件，wx.onRouteChange能感知路由的变化。如果能提供before，after的hook是极好的。至少能提供wx.onRouteBack是最基础的吧，因为页面的回退可以不受代码控制（点击左上角 < 图标），这使得路由变化无法感知，因此，想封装高阶接口代理小程序基础的路由功能就无法完成，因为，只能感知路由前进（navigatoTo,redirectTo都需要写代码完成，没有其他方式），无法感知路由后退，就无法形成逻辑闭环，即无法维护完整的路由栈信息。想做更友好更高阶的路由功能成了不可完成的事情。

感觉官方人员应该多看看当下主流的框架（如VUE），看看当下流行框架强大而丰富的路由功能，借鉴借鉴经验。没有要求小程序官方提供高级特性，但至少应该提供基础特性供开发者自行封装和迭代吧。

如果你不知道使用 Component 构造器构造页面，请点击左边的蓝色字。

如果没有拦截（或改变）的意图，我们有个即将开放的接口仅用于“读取”（目前正在处理一些 edge case，之后会新增）。

小程序的基础架构、设计目标和基础库更新方式与常见框架并不一样，所以很多高层接口也不一样，请理解。