核心是区分数据更新与版本更新；onshow中用uni.getlaunchoptionssync()获取真实唤起参数，pinia store需watch监听并storetorefs解构；onpulldownrefresh须手动调用加载函数并stop；需结合缓存判断唤起差异。
uni-app 动态更新小程序内容，核心不是“刷新页面”，而是分清「数据更新」和「版本更新」两个完全不同的维度——前者是业务逻辑（比如拉新数据、响应参数变化），后者是客户端行为（比如下载新代码包）。混用或错判会导致白屏、参数丢失、用户看不到新功能。
onShow 里调用 uni.getLaunchOptionsSync() 拿最新 query 和 scene
小程序被微信聊天、公众号、扫码等外部方式唤醒时，onLoad 不会再次触发，但 onShow 一定执行。此时必须靠 uni.getLaunchOptionsSync() 获取真实跳转参数，否则页面永远读不到新参数。
-
onLoad(options)只管内部路由跳转（如uni.navigateTo({ url: '/pages/detail?id=123' })），拿到的是字符串键值对 -
uni.getLaunchOptionsSync()返回的是完整对象，含query（已自动解码）、scene（数字码，如 1007）、shareTicket等 - 安卓微信中
onShow的options常为空，不能依赖它；getCurrentPages().pop().options也只反映上一次onLoad的传参，不是当前唤起上下文 - 测试务必切到「体验版」或「正式版」：开发版下
scene恒为 1001，无实际意义
用 Pinia store + watch 监听 launchOptions.query 实现全局响应
单纯把参数存进 store 不等于“动态响应”——Vue 响应式需要显式监听。Pinia 是当前 uni-app（尤其 Vue3）的事实标准，但 store 本身不会自动感知参数变化，必须由生命周期驱动同步。
- 在
App.vue的onShow中调用store.setLaunchOptions(uni.getLaunchOptionsSync()) - store 内部用
watch(() => store.launchOptions.query, ... , { shallow: false })监听深层变化 - 页面组件必须用
storeToRefs解构字段，否则响应式失效 - 不要在 store 初始化时就调用
uni.getLaunchOptionsSync()：冷启动前该 API 可能返回空对象
页面内手动触发数据重载，别依赖 onPullDownRefresh 自动刷新
onPullDownRefresh 是 UI 交互钩子，不是数据刷新逻辑的容器。它不自动执行任何请求，也不保证与你当前的数据状态一致——比如下拉时用户可能已切换 tab 或离开页面。
- 必须在
onPullDownRefresh回调里显式调用数据加载函数（如this.fetchList()） - 加载完成后需手动调用
uni.stopPullDownRefresh()，否则下拉动画卡住 - 如果列表依赖 URL 参数（如
?id=xxx），下拉时要确保参数没变；否则得先uni.navigateBack()再重新进入，或用uni.reLaunch()强制刷新栈 - 避免在
onPullDownRefresh里直接修改data，应走统一 action 或 service 层，便于复用和测试
真正难的是区分「哪次唤起」，而不是读取参数
小程序没有会话 ID，scene 和 query 本身不带时间戳或唯一标识。同一个二维码扫两次，参数可能完全一样，但业务上要当成两次独立操作（比如领券、打卡）。这时候不能只比对值，得结合本地缓存做差异判断：
- 在
onShow中缓存上一次的scene和query.id - 对比发现变化，再触发业务逻辑（如重置表单、清除缓存、上报埋点）
- 注意 iOS 微信中
referralInfo存在但安卓没有，跨平台逻辑要兜底
