Entrar Agora 小程序这几年铺得快，很大程度是因为它足够轻，多数操作不用跳出微信就能完成。但项目一旦复杂起来，几乎不可能只靠一个页面撑着。列表要进详情，活动页要跳报名表单，商品卡片可能要点进客服会话，这些场景都绕不开页面跳转。跳得顺不顺，直接决定用户会不会在中间流失。所以把小程序跳转这件事理清楚，其实比想象中更重要。
开发中处理页面跳转，通常有两种思路：一种是基于页面栈的常规跳转，另一种是借助组件事件或事件通道，用通信来带动跳转。二者不是替代关系，更多要看具体场景。
先说页面栈。小程序打开第一个页面后，内部就会维护一个页面栈。可以把它想成一摞卡片：新打开的页面放在最上面，原来的页面还在栈里，只是暂时被盖住；返回时抽掉最上面那张，之前的界面就露出来了。这样做的好处是页面状态能保留，返回时不用重新加载。
基于页面栈跳转，最常用的 API 是 wx.navigateTo。它适合列表到详情、首页到设置页这类层级清晰的单向跳转。比如从新闻列表点进某一篇文章：
// 列表页点击进入详情
wx.navigateTo({
url: '/pages/detail/detail?id=' + id
})
// 详情页接收参数
Page({
data: {
id: ''
},
onLoad(options) {
this.setData({ id: options.id })
}
})
这种写法代码最少，理解起来也直观。但要注意，页面栈有深度限制，一般最多十层。如果一直用
navigateTo 打开新页面，用户点返回会很累。遇到那种不需要返回的页面，可以换成 wx.redirectTo 替换当前页；如果目标是 tabBar 页面，还要改用 wx.switchTab。这些细节在实际项目里很容易踩坑。第二种思路更灵活一些。很多跳转并不是打开新页面就结束了，还需要把新页面里的数据带回来，或者跳转动作本身藏在某个自定义组件里。这种时候只靠 URL 传参就不太够，传复杂对象会很别扭，参数一多还容易拼错。更稳妥的做法是先把页面之间的通信打通，再决定往哪里跳、带什么数据。
小程序基础库从 2.7.3 开始支持
eventChannel，就是专门处理这类情况的。父页面在 navigateTo 时可以监听事件，目标页面通过 getOpenerEventChannel 拿到通道，然后在返回前把结果回传。一个很典型的场景是：从表单页跳到一个日期选择页，选完日期后自动带回表单，不必再让用户手动填写。// 表单页打开日期选择页，并监听回传
wx.navigateTo({
url: '/pages/date-picker/date-picker',
events: {
acceptDateFromOpenedPage(data) {
console.log('收到的日期：', data.date)
}
}
})
<img src="/uploads/20251015/22.png?t=1916106175" alt="" class="img-fluid" />
// 日期选择页确认后回传并返回
onConfirm() {
const eventChannel = this.getOpenerEventChannel()
eventChannel.emit('acceptDateFromOpenedPage', { date: '2026-07-15' })
wx.navigateBack()
}
这样数据返回时已经回到上一页，不必在全局状态里绕一圈。同样，如果跳转动作放在自定义组件内部，也尽量不要让组件自己直接操作页面栈。更合理的做法是组件向外
triggerEvent，把点击事件交给页面统一处理，由页面来调用 wx.navigateTo。这样组件职责更单一，后续维护起来也不会因为跳转逻辑分散而头疼。怎么选？如果只是打开一个新页面，没有复杂的数据回传，页面栈跳转就够，代码最省。如果跳转前后有数据来回、同一个页面被多个入口复用，或者跳转动作藏在组件里，就值得把通信逻辑单独设计。实际项目里往往混着用：常规跳转走页面栈，涉及数据回传或组件触发时再用事件通道。
跳转能力看着基础，但用好了能明显减少逻辑绕圈和页面卡顿。现在越来越多业务往小程序里搬，页面关系只会更复杂。提前把跳转路径和通信方式想清楚，后面迭代会省不少事。往后如果小程序继续放开更多页面能力，这类交互大概率会更接近原生应用的体验。