小程序生命周期与页面路由：餐厅营业全流程

可视化演示

演示小程序App/Page/Component生命周期回调与页面栈路由跳转机制。

应用生命周期：餐厅的开门与打烊

一家餐厅每天的开业节奏是固定的：开门前采购备料，门一开迎客，忙完一轮暂时歇口气，客人走了再重新迎接。小程序 App 的生命周期也是如此——它就是整个餐厅的营业时间表。onLaunch 是开门前的备料环节，小程序冷启动时只触发一次；onShow 是正式开门迎客，每次从后台回到前台都会触发；onHide 是挂上“暂停营业”的牌子；onError 则是后厨着火时的应急机制。

从技术角度讲，App 级生命周期回调在小程序的 app.js 中定义，是整个应用的“总开关”。onLaunch 适合做初始化工作，比如检查登录状态、拉取全局配置；onShow 适合恢复需要实时更新的数据；onHide 适合暂停正在播放的音频、关闭高频定位。它们的触发时机由微信/支付宝/抖音等平台统一调度，开发者只需在对应回调里填入合适的“工作清单”。

用一个时间轴可以更清楚地看出规律：应用从启动开始，经历“前台-后台-前台”的循环，直到用户退出小程序。注意 onShow 和 onHide 是成对出现的，而 onLaunch 一生只会出现一次。这个规律决定了全局资源的加载与释放时机。

开一家店，老板必须知道什么时候备料、什么时候开门、什么时候打烊。小程序全局的状态管理也是这样：把初始化放进 onLaunch，把恢复动作放进 onShow，把暂停动作放进 onHide，这台餐厅永远不会在错误的时间做错误的事。

页面生命周期：一桌客人的用餐全程

餐厅的每张餐桌都有自己独立的“接待流程”：客人进门被引导入座，服务员递上菜单，后厨开始备菜，客人用完餐结账离开，服务员撤桌清扫。小程序里每个页面 Page 的生命周期，就是这张餐桌的完整服务流程。当 onLoad 触发时，相当于客人刚入座，服务员递上点菜单；onShow 是客人真正看到这桌的状态；onReady 是菜品和餐具全部就位；onHide 是客人暂时离席；onUnload 则是客人结账走人、撤桌清洁。

在代码层面，页面生命周期回调是每个 Page 的标配。首次进入页面时回调顺序固定为 onLoad → onShow → onReady。其中 onLoad 只执行一次，且能接收上一个页面通过路由带来的参数；onShow 每次页面变得可见都会触发；onReady 表示首帧渲染完成，可以安全操作组件。当页面被 navigateTo 压入后台时触发 onHide，被 navigateBack 或 redirectTo 移除时触发 onUnload。

理解这套顺序的价值在于掌握“资源分配”的时机。onLoad 适合拉取数据、初始化变量；onReady 适合获取节点信息、开始动画；onUnload 必须清理该页面专属的定时器和监听器，否则相当于客人走了，桌上的餐具和垃圾没人收拾，越积越多。

客人走后不撤桌，下一桌客人就没法入座。同理，页面被卸载时不清除定时器、不解绑监听，内存就会持续膨胀。把 onUnload 当成“撤桌流程”，每次必做清理，你的小程序就能长时间流畅运行。

组件生命周期：餐具的流转

好的餐厅离不开餐具的高效流转。刀叉、盘子、杯子从仓库取出、摆上桌、被使用、最后撤下清洗，构成一个完整的循环。小程序的自定义组件 Component 也有类似的生命周期：created 相当于餐具从仓库取出（此时组件实例已创建但还没上桌）；attached 相当于餐具被摆到餐桌上（组件挂载进页面节点树）；ready 是餐具各就各位、可以正式使用；detached 是撤桌清洗（组件从节点树移除）。

技术细节上，组件生命周期建议写在 lifetimes 字段中。created 时组件还没有进入到页面结构里，所以不能调用 this.triggerEvent 之类依赖组件关系的接口，但可以初始化自身数据；attached 之后可以获取组件上下文；ready 之后可以安全操作组件内部的节点。除此之外还有 observers 字段用于监听属性变化——就像服务员时刻留意客人的水杯，一旦空了就主动加水。

组件生命周期与页面生命周期的关系是“嵌套”的：页面 onLoad 时内部的组件可能正在走 created → attached，页面 onReady 时组件的 ready 也通常已结束。开发者在小程序工具中打开生命周期跟踪面板，可以直观看到这种“先父后子、子先就绪”的触发层次。

餐具流转不清洗会滋生细菌，组件销毁不清理会泄漏内存。把 detached 当作“撤桌清洗”的固定流程，组件就能在页面任何角落安全反复地使用。

路由跳转方式：客人的四种移动动线

客人在餐厅里的移动方式不止一种：从大厅走到包间，服务员会记住他的来路方便带他回来；从包间直接换到另一间包间，原包间立即被回收；吃完原路返回；或者通过固定通道去吧台取饮料。小程序页面路由的四种 API 恰好对应这四种动线。navigateTo 是“走进包间”，新页面压入页面栈，当前页保留在栈中并隐藏；redirectTo 是“换桌”，当前页被替换出栈并卸载；navigateBack 是“原路返回”，弹出栈顶页面；switchTab 是“走通道去吧台”，只能跳转到 tabBar 页面且不能携带参数。

代码层面，这些 API 都是全局方法：wx.navigateTo、wx.redirectTo、wx.navigateBack、wx.switchTab，以及“清场重来”的 wx.reLaunch。用栈的视角看，navigateTo 就是 push，navigateBack 就是 pop，redirectTo 是“弹出栈顶再压入新页”，switchTab 则特殊地清空非 tabBar 页面。选择哪种方式取决于业务语义：需要返回上一页就用 navigateTo，完成操作后不希望用户回到旧页面就用 redirectTo。

一个常见的业务场景是登录流程：用户从首页进入登录页，登录成功后应该用 redirectTo 跳回首页或业务页，而不是 navigateTo，否则用户按返回键又会回到登录页，就像换桌后服务员还带客人回已经撤掉的旧桌。

动线设计决定客人体验。支付成功后用 redirectTo 防止回退到收银台，详情页跳转用 navigateTo 确保用户可以逐级返回。路由 API 选对了，用户在小程序里的每一步都走得顺理成章。

页面栈管理：服务员的动线账本

服务员手里有一本动线账本，每次带客人去新包间就记一笔，客人离开就划掉一笔，账本的深度有限。小程序正是用“页面栈”来管理所有页面的。页面栈是一个后进先出的结构：navigateTo 入栈，navigateBack 出栈，redirectTo 替换栈顶。平台对栈深度有硬性限制——最多 10 层，超过后会跳转失败，就像账本最多只能记 10 条动线，写满了就不能再带客人去新包间。

开发者可以通过 getCurrentPages() 获取当前页面栈的数组，最后一个元素就是当前页面实例。利用这个 API 可以做两件很实用的事：一是拿到上一页实例并调用它的方法更新数据，二是打印当前栈结构排查路由异常。页面栈的进出规则决定了 onShow 与 onUnload 的触发顺序——入栈时新页面 onLoad 后 onShow，旧页面 onHide；出栈时栈顶页面 onUnload，新栈顶页面 onShow。

栈深度限制是新手最容易踩的坑。如果页面反复用 navigateTo 跳转而不及时 navigateBack，到第 11 次跳转就会失败。所以在设计“详情页 → 评论页 → 举报页”这类深层链路时，务必评估某些中间页是否应用 redirectTo 替换掉，主动控制账本厚度。

动线账本记得太多，服务员会手忙脚乱。小程序同样如此——定期用 getCurrentPages() 检查栈深度，用 redirectTo 代替无意义的 navigateTo 链路，你的页面导航就不会“爆栈”。

参数传递机制：点菜单上的需求条

客人想吃什么，写在点菜单上递给后厨；客人有什么忌口，记录在餐厅的熟客档案里；服务员之间需要实时沟通，直接通过对讲机喊话。小程序页面之间的数据传递同样有三种主要通道。第一种是 query 参数：跳转时把数据拼在 URL 后面，目标页在 onLoad(options) 中接收，就像点菜单上写明“少辣、不要香菜”。第二种是全局数据 app.globalData：挂载在 App 实例上的公共对象，适合存放登录令牌、用户信息，相当于餐厅的公用档案。第三种是本地缓存 wx.setStorageSync：把数据持久化到设备存储中，适合存放草稿、历史记录，相当于熟客档案柜。

实战中 parameter 传递的细节容易被忽略：navigateTo 的 URL 长度有限且需要编码特殊字符，对象类型必须先 JSON.stringify 再传；switchTab 不能带参数，此时应借助全局变量或缓存；EventChannel 可以在两个页面间建立双通道通信，类似给服务员配备对讲机，navigateTo 成功回调里通过 eventChannel.emit 传输数据，目标页在 onLoad 里 getOpenerEventChannel().on 监听接收。

选择哪种通道没有绝对标准，核心是数据和生命周期要匹配：临时一次性数据走 query，会话级数据走 globalData，需要跨冷启动保留的数据走缓存，父子页面间的即时回传走 EventChannel。

传参方式没有银弹，只有最合适的场景。把一次性需求写在“点菜单”上，把长期信息放进“档案柜”，把临时协作丢给“对讲机”，你的页面间数据流就会像餐厅后厨一样井然有序。

缓存与内存：食材保鲜与库存管理

再大的餐厅也有冰柜容量上限；再稳的小程序也有存储限制。本地缓存就像餐厅的冰柜——里面可以存熟客口味、半成品食材等，但冰柜总共只有 10MB 空间，超过上限后写入失败。缓存 API 分为同步与异步两套：wx.setStorageSync / wx.getStorageSync 是“吧台即时存取”，读写快但会阻塞 JS 线程；wx.setStorage / wx.getStorage 是“后仓批量存取”，不阻塞主线程，适合大体积数据。除了总量上限，还要注意缓存数据在用户清理微信缓存时会丢失，所以不能把它当作永久数据库。

与缓存同等重要的是内存管理。页面的 onUnload 必须清理定时器和监听器，否则“撤桌不洗碗”会引发内存泄漏；onHide 时应该暂停视频和音频播放，减少后台占用；图片资源尽量走 CDN 懒加载，避免一次加载过多大图。组件销毁时同样要清理 observers 之外的动态监听。内存清理的黄金法则是：谁创建，谁释放。

实际开发中，缓存策略和生命周期的配合非常关键：在 onLoad 中先读缓存展示旧数据，再发请求更新数据并写回缓存——这是“缓存优先、网络兜底”的经典模式；在 onUnload 中把用户编辑的草稿写入缓存，防止误退出丢数据。这样既保证了首屏速度，又照顾了数据新鲜度。

把缓存当成冰柜、把内存当成后厨空间，定期“清库存”是经验丰富的老板的必修课。定时器清掉、监听器解绑、大图懒加载、缓存限量使用，这套组合拳打下来，小程序就能像高效运转的餐厅一样长期不卡顿。

AI 应用场景

Python 演示

class Page:    def __init__(self, name):        self.name = name     def on_load(self, params):        print("[Page:%s] onLoad, params=%s" % (self.name, params))     def on_show(self):        print("[Page:%s] onShow" % self.name)     def on_ready(self):        print("[Page:%s] onReady" % self.name)     def on_hide(self):        print("[Page:%s] onHide" % self.name)     def on_unload(self):        print("[Page:%s] onUnload" % self.name)  class MiniApp:    MAX_DEPTH = 10     def __init__(self):        self.stack = []        self.global_data = {}     def launch(self):        print("[App] onLaunch")        self.show()     def show(self):        print("[App] onShow")     def hide(self):        print("[App] onHide")     def navigate_to(self, page, params=None):        if len(self.stack) >= self.MAX_DEPTH:            raise RuntimeError("page stack is full")        if self.stack:            self.stack[-1].on_hide()        self.stack.append(page)        page.on_load(params or {})        page.on_show()        page.on_ready()     def redirect_to(self, page, params=None):        self.stack.pop().on_unload()        self.stack.append(page)        page.on_load(params or {})        page.on_show()        page.on_ready()     def back(self, delta=1):        for _ in range(delta):            self.stack.pop().on_unload()        if self.stack:            self.stack[-1].on_show()  if __name__ == "__main__":    app = MiniApp()    app.launch()    home = Page("home")    app.navigate_to(home)    detail = Page("detail")    app.navigate_to(detail, {"id": 1001})    app.back()    edit = Page("edit")    app.redirect_to(edit)

1. class Page:定义页面模型，每个页面拥有 onLoad、onShow、onReady、onHide、onUnload 五个生命周期方法，对应正文中的“餐桌服务流程”。
2. def on_load(self, params):模拟页面接收路由参数，对应实际小程序中 onLoad(options) 接收 query 参数。
3. self.stack = []用列表模拟页面栈，栈顶永远是列表末尾元素，对应“服务员的动线账本”。
4. if len(self.stack) >= self.MAX_DEPTH:校验栈深度是否超过 10 层，超过则抛出异常，对应平台的栈深限制。
5. self.stack[-1].on_hide()压入新页面前，先将当前栈顶页面隐藏，符合 navigateTo 的时序。
6. self.stack.append(page)新页面入栈，相当于服务员在账本上新记一条动线。
7. self.stack.pop().on_unload()弹出栈顶页面并触发其 onUnload，对应 navigateBack 的撤桌流程。
8. def back(self, delta=1):按指定步数出栈，出栈后让新栈顶页面触发 onShow，对应“原路返回”。

常见误区

面试题