真正的动态响应需在onShow中调用uni.getLaunchOptionsSync()获取最新参数，Pinia store配合watch监听query变化实现全局响应式更新，避免依赖onLoad选项或globalData。
不能靠 globalData 或 Vue.prototype 实现真正的“动态响应”——它们只在初始化时赋值一次，后续参数变化完全不可见。
onShow 中必须用 uni.getLaunchOptionsSync() 拿最新跳转参数
小程序被其他应用（如微信聊天、公众号）唤醒时，onLaunch 不会再次触发，但 onShow 一定触发。此时 options 参数可能为空或不完整，尤其在安卓微信中常见。
-
uni.getLaunchOptionsSync()返回的是当前「最后一次」启动/显示时的完整参数对象，包含query、scene、shareTicket等，且在onShow里调用始终有效 - 不要依赖
getCurrentPages().pop().options：它只反映页面栈顶层页面的 onLoad 传参，无法捕获冷启动后热切换带来的新extraData - 若需监听参数变更，可在
onShow内比对上一次缓存的scene或query.id，有差异再触发业务逻辑
Pinia store + onShow 同步更新是最稳妥的全局响应方案
用 Pinia 替代 vuex 是当前 uni-app（尤其是 Vue3 项目）的事实标准。关键在于：store 本身不自动感知参数变化，必须由生命周期主动驱动同步。
- 在
App.vue的onShow中调用store.setLaunchOptions(uni.getLaunchOptionsSync()) - store 内部用
watch监听launchOptions.query变化（需 shallow: false），触发 computed 或 action - 避免在 store 初始化时就调用
uni.getLaunchOptionsSync()：冷启动前该 API 可能返回空对象 - 注意：HBuilderX 4.20+ 对
onShow中的 Pinia 更新已支持响应式渲染，但需确保页面组件使用storeToRefs解构响应式字段
onLoad 和 onShow 的参数来源完全不同，混用必丢数据
onLoad(options) 的 options 来自页面路由跳转（如 uni.navigateTo），而 onShow 需要处理的是跨 App / 小程序场景下的 extraData，两者结构和语义不兼容。
-
onLoad的options是字符串键值对，如{ id: '123', type: 'detail' } -
uni.getLaunchOptionsSync()返回的query是 URL 解析后的对象，scene是数字码（如1007表示公众号菜单），referralInfo在 iOS 微信中才存在 - 若页面同时支持内部跳转和外部唤起，必须分别处理：
onLoad处理前者，onShow+getLaunchOptionsSync处理后者 - 测试时务必切到「体验版」和「正式版」验证：开发版下
scene恒为1001，无实际意义
真正难的不是读取参数，而是判断「这个参数到底属于哪一次唤起」——小程序没有唯一会话 ID，scene 和 query 组合才是上下文锚点，任何试图用单字段做状态判断的方案都会在多任务切换时失效。
