onLoad → onShow → onReady 是页面首次进入时的固定顺序：onLoad 初始化数据源并解析URL参数，onShow 响应页面每次进入前台，onReady 确保视图层渲染完成可操作DOM。
onLoad → onShow → onReady 是固定顺序，不可跳过、不可重排，且只在页面首次进入时严格按此执行。
onLoad 为什么必须在 onShow 之前？
因为 onLoad 是页面生命周期的起点，负责接收 URL 参数（options）并初始化数据源；此时页面尚未“可见”，但逻辑上已开始加载。框架必须先完成参数解析和初始数据准备，才能决定是否显示、显示什么内容。
-
onLoad中不能依赖this.data，它还是空对象——要用options传参，比如uni.navigateTo({ url: 'pages/detail?id=123' })后，onLoad({ id: '123' })直接可用 - 如果把刷新逻辑（如拉取最新列表）写在
onLoad，tabBar 切换回来时不会触发，导致数据陈旧 - H5 端若在
onLoad里调this.$nextTick可能不生效，得降级用setTimeout(() => {}, 0)
onShow 触发时机比你想象中更频繁
onShow 不是“页面渲染完才触发”，而是“页面进入前台即触发”，哪怕 DOM 还没 ready。它和 onLoad 的关系不是“先后替代”，而是“首次加载 + 后续可见”的分工。
- 常见触发场景：从其他页面
uni.navigateBack()返回、从 tabbar 切换回来、小程序从后台切回前台、App 端热启动回到当前页 - 只要页面没被销毁（比如没走
onUnload），每次重新“露脸”都会触发onShow，所以适合放轮播图刷新、未读数更新、播放器恢复等逻辑 - iOS 微信小程序中，
onHide可能延迟触发，别指望靠它立刻停音频或清定时器
onReady 为什么不能早于 onShow？
onReady 表示视图层真正就绪，此时才能安全操作 DOM 节点。它晚于 onShow，是因为平台渲染机制决定了：页面先“声明可见”（onShow），再“真实绘制完成”（onReady）。
- 必须在这里调
uni.createSelectorQuery()、this.$refs.xxx或 canvas 初始化，否则查不到节点或报错 - 如果在
onShow里就操作 DOM，H5 端可能取到null，App 和小程序端表现也不一致 - 组件内 Vue 生命周期（如
mounted）和onReady接近但不等价：mounted是 Vue 实例挂载完成，onReady是 uni-app 渲染器确认 DOM 可用
最容易被忽略的是：tabBar 页面切换时，onLoad 不会重复执行，但 onShow 必定触发——这意味着所有“需要每次看到都生效”的逻辑，必须放在 onShow，而不是凭经验塞进 onLoad。
