Vue微信分享参数丢失解决方案：URL Hash+sessionStorage+localStorage三重保险

1. 这个“参数消失”问题，不是Bug，是微信分享机制的必然结果

你刚在Vue项目里调试好一个带参数的分享链接，比如https://example.com/share?uid=123&source=wechat&scene=invite，页面也正常渲染了用户ID和来源标识。可一旦点击微信右上角“分享到朋友圈”或“发送给朋友”，再点开别人转发来的链接——参数全没了，或者只剩?scene=invite，甚至变成一串带__biz和t的长字符串。你刷新、清缓存、换手机、重装微信……都没用。这不是你的Vue路由配置错了，也不是后端接口挂了，更不是CDN缓存没刷干净。这是微信JS-SDK分享接口在主动剥离你传入的原始URL参数，而且它干得非常彻底、非常安静、非常符合规范。

这个现象在Vue单页应用（SPA）中尤其刺眼。因为Vue Router默认使用history模式，整个页面跳转不刷新，URL变化靠pushState劫持。而微信分享时调用的wx.onMenuShareTimeline或新版wx.shareTimeline，其底层逻辑是：以当前浏览器地址栏显示的URL为唯一可信源，提取并标准化该URL，再将其作为分享卡片的跳转目标。它不会读取你代码里构造的shareUrl变量，也不会关心你router.push时带了多少query。它只认地址栏里那个“人眼可见”的URL。而这个URL，在Vue SPA里，往往是你在mounted或created钩子中动态拼接出来的，比如通过this.$route.fullPath获取。但问题就出在这里——this.$route.fullPath返回的是Vue Router解析后的路径，它可能已经经过了encodeURI处理，也可能被base前缀污染，还可能在iOS微信里因location.hash残留导致解析错乱。更关键的是，微信客户端在生成分享卡片时，会执行一套自己的URL规范化流程：自动移除重复参数、对特殊字符进行二次编码、截断过长的query string（实测超过1024字符会被强制截断），甚至将某些敏感字段（如code、state、access_token）直接过滤。这不是微信在“针对”你，而是它为了保障分享链路的安全性与一致性，内置的一套防御性策略。

我最早在某高校实验室的一个招生宣传H5项目里撞上这个问题。当时需求是：每个招生老师生成专属分享链接，带?teacher_id=789&campus=shanghai，用户点击后能精准归因。我们用Vue 2 + Vue Router history模式开发，本地测试一切完美。上线后第一天，老师反馈“分享出去的链接点开全是首页”。排查了整整两天，从Nginx重写规则查到CDN缓存头，最后才意识到：微信根本没把我们shareUrl里写的完整URL当回事。它只抓取了地址栏里那个https://h5.example.edu.cn/?teacher_id=789，然后在内部做了decodeURIComponent再encodeURIComponent的双重处理，导致&campus=shanghai里的&被误判为分隔符，整个参数串被截断。这个教训让我明白，与其把希望寄托在“让微信别改我的URL”，不如从根本上重构分享参数的承载方式——把参数从URL query里“请”出来，放到微信愿意原样保留的地方去。

2. 微信分享参数的三重“保险柜”：为什么localStorage、sessionStorage和URL Hash才是真解

面对微信对URL query的“暴力清洗”，最直接的反应是：“那我换个地方存参数！”但换哪里？很多人第一反应是localStorage。这没错，但它只是解决方案的起点，而非终点。真正可靠的方案，必须同时满足三个硬性条件：微信客户端能读取、Vue应用启动时能还原、用户多次分享不冲突。这就引出了参数存储的“三重保险柜”模型——不是三选一，而是按场景分层使用。

2.1 第一层保险柜：URL Hash（#后内容）——微信最宽容的“白名单”

微信对URL中#后面的内容（即hash fragment）几乎不做任何干预。它既不解析，也不编码，更不截断。https://example.com/#/share?uid=123&source=wechat和https://example.com/#uid=123&source=wechat在微信分享时，hash部分会被100%原样保留。这是因为hash本身是前端路由的基石，微信明确将其视为“纯客户端行为”，不参与服务端跳转或安全校验。所以，第一步改造就是：把所有需要持久化、且必须随分享链接传递的参数，全部挪到URL hash里。

在Vue Router中，这需要两步操作。首先，配置Router使用hash模式（如果你还在用history，现在就是切换的最佳时机）：

// router/index.js export default new Router({ mode: 'hash', // 关键！强制使用hash模式 base: process.env.BASE_URL, routes: [ { path: '/share', name: 'SharePage', component: () => import('@/views/SharePage.vue') } ] })

其次，在生成分享链接时，不再拼接query，而是构造hash：

// utils/shareHelper.js export function buildShareUrl(uid, source) { // 不再用 ?uid=123&source=wechat // 改用 #uid=123&source=wechat return `${window.location.origin}${window.location.pathname}#uid=${encodeURIComponent(uid)}&source=${encodeURIComponent(source)}` }

这样生成的分享链接，无论微信如何“蹂躏”，#uid=123&source=wechat这部分永远岿然不动。我在某跨平台教育App的家长邀请模块中验证过，即使分享链接长达2000字符，hash部分依然完整无损。但Hash有局限：它无法触发服务端渲染（SSR）的初始数据加载，如果用户直接打开带hash的链接，Vue应用启动后需要手动解析hash并fetch数据。这就引出了第二层保险柜。

2.2 第二层保险柜：sessionStorage——页面级“临时保险箱”

sessionStorage的生命周期与当前浏览器标签页完全绑定，关闭标签即销毁，完美匹配一次分享-点击-落地的闭环。它的优势在于：Vue应用启动时，可以立即读取，无需等待路由解析；且微信分享不会清空它。具体操作是：在用户触发分享动作的瞬间（比如点击“分享给好友”按钮），将参数写入sessionStorage：

// components/ShareButton.vue methods: { handleShare() { const params = { uid: this.userId, source: 'wechat_invite', timestamp: Date.now() } // 序列化后存入sessionStorage sessionStorage.setItem('shareParams', JSON.stringify(params)) // 调用微信分享接口 wx.shareTimeline({ title: '快来看我的学习成果！', link: window.location.href, // 此时href已含正确hash imgUrl: this.shareImage }) } }

然后，在SharePage.vue的created或mounted钩子里，优先读取sessionStorage：

// views/SharePage.vue created() { // 1. 尝试从sessionStorage读取（最高优先级） const storedParams = sessionStorage.getItem('shareParams') if (storedParams) { try { this.shareParams = JSON.parse(storedParams) // 清空，避免重复使用 sessionStorage.removeItem('shareParams') return } catch (e) { console.warn('sessionStorage params parse failed', e) } } // 2. 降级：从URL hash解析 this.parseHashParams() }

这个设计的关键在于“优先级”：sessionStorage是“活参数”，代表用户本次主动分享的意图；URL hash是“死参数”，是分享链接的静态快照。两者结合，既能保证首次落地页的数据准确，又能支持用户复制链接后二次传播。

2.3 第三层保险柜：localStorage + 时间戳校验——跨会话“长效凭证”

localStorage的问题是永久性。如果用户昨天分享了一个链接，今天又分享另一个，localStorage里的旧参数不会自动覆盖，导致归因错乱。解决方案是引入时间戳+命名空间隔离：

// utils/persistentStorage.js export class ShareParamStore { static set(uid, source, scene) { const key = `share_${Date.now()}` // 用时间戳做key，确保唯一 const value = { uid, source, scene, createdAt: Date.now() } localStorage.setItem(key, JSON.stringify(value)) // 同时存一个“最新key”的索引，方便快速读取 localStorage.setItem('share_latest_key', key) } static get() { const latestKey = localStorage.getItem('share_latest_key') if (!latestKey) return null const item = localStorage.getItem(latestKey) if (!item) return null try { const data = JSON.parse(item) // 检查是否过期（比如24小时） if (Date.now() - data.createdAt > 24 * 60 * 60 * 1000) { this.clear(latestKey) return null } return data } catch (e) { this.clear(latestKey) return null } } static clear(key) { localStorage.removeItem(key) localStorage.removeItem('share_latest_key') } }

在分享时调用ShareParamStore.set()，在落地页调用ShareParamStore.get()。这样，即使用户关闭浏览器再打开，只要在24小时内，参数依然有效。我在某电商小程序的裂变活动里用过这套方案，实测用户从微信聊天窗口点击链接，到完成注册，全程参数零丢失。而localStorage的持久性，恰好弥补了sessionStorage在“用户先分享、再关浏览器、第二天才点开”这种长周期场景下的空白。

提示：三重保险柜不是堆砌，而是按需组合。对于即时性强、要求100%准确的场景（如支付回调），必须用sessionStorage；对于需要跨天追踪的营销活动，localStorage是刚需；而URL Hash则是所有方案的底层兜底，确保链接本身具备自解释能力。

3. Vue Router的深度适配：从路由守卫到动态路由的无缝衔接

光有参数存储还不够。Vue Router作为SPA的导航中枢，必须与微信分享的“非标准跳转”行为深度耦合。微信分享卡片的跳转，本质上是一次强制的、不可拦截的页面刷新（即使你用hash模式）。这意味着，用户点击分享链接后，浏览器会重新加载整个页面，Vue实例被销毁重建。此时，router.beforeEach守卫、router.afterEach钩子、甚至<keep-alive>的缓存状态，全部失效。我们必须在Vue应用“重生”的第一时间，把参数注入到路由系统中，让后续的组件逻辑像什么都没发生过一样运行。

3.1 路由守卫的“预加载”策略：在create之前就拿到参数

常规做法是在mounted里解析参数，但这有个致命缺陷：如果SharePage.vue依赖某个asyncData函数（比如根据uid拉取用户信息），而asyncData在created钩子中调用，那么created执行时，参数可能还没从sessionStorage或localStorage读取完毕。解决方案是：把参数解析提前到Vue实例创建之前，也就是在main.js的new Vue()之前完成。

// main.js import { createApp } from 'vue' import App from './App.vue' import router from './router' import { ShareParamStore } from './utils/persistentStorage' // 在Vue实例创建前，预解析分享参数 function preloadShareParams() { // 1. 优先检查sessionStorage（本次会话内分享） const sessionParams = sessionStorage.getItem('shareParams') if (sessionParams) { try { const params = JSON.parse(sessionParams) // 将参数挂载到全局，供router和组件使用 window.__SHARE_PARAMS__ = params sessionStorage.removeItem('shareParams') return } catch (e) {} } // 2. 检查localStorage（跨会话） const localParams = ShareParamStore.get() if (localParams) { window.__SHARE_PARAMS__ = localParams return } // 3. 最后解析URL hash（兜底） const hashParams = parseHashParams() if (Object.keys(hashParams).length > 0) { window.__SHARE_PARAMS__ = hashParams } } // 解析hash的工具函数 function parseHashParams() { const hash = window.location.hash if (!hash || !hash.includes('?')) return {} const queryString = hash.split('?')[1] const params = new URLSearchParams(queryString) const result = {} for (let [key, value] of params) { result[key] = decodeURIComponent(value) } return result } // 执行预加载 preloadShareParams() // 创建Vue应用 const app = createApp(App) app.use(router) app.mount('#app')

这样，当SharePage.vue的created钩子执行时，window.__SHARE_PARAMS__已经是一个可用的对象。你可以直接在asyncData中使用：

// views/SharePage.vue export default { async created() { // 直接使用预加载的参数 if (window.__SHARE_PARAMS__) { this.userData = await fetchUserById(window.__SHARE_PARAMS__.uid) this.source = window.__SHARE_PARAMS__.source } } }

这个“预加载”策略，把参数获取的耗时（IO操作）从组件生命周期里剥离，确保了数据流的确定性。

3.2 动态路由的“伪静态化”：让/share/123这样的路径也能携带参数

很多团队会纠结：能不能让分享链接看起来更“专业”，比如https://example.com/share/123而不是https://example.com/#uid=123？答案是可以，但需要绕过微信的限制。核心思路是：用动态路由路径（/share/:uid）作为入口，但实际参数仍由sessionStorage或localStorage提供，路由只是个“漂亮外壳”。

首先，配置动态路由：

// router/index.js { path: '/share/:uid', name: 'DynamicShare', component: () => import('@/views/SharePage.vue'), props: true // 将路由参数自动注入组件props }

然后，在分享按钮中，生成带动态路径的链接：

// 分享时生成 https://example.com/share/123 const shareUrl = `${window.location.origin}/share/${this.userId}`

关键来了：当用户点击这个链接，浏览器会加载/share/123，Vue Router会匹配到DynamicShare路由，并把123作为$route.params.uid传入。但此时，source、scene等其他参数呢？它们不在路径里。所以，我们在handleShare()中，依然要把完整参数存入sessionStorage：

handleShare() { const params = { uid: this.userId, source: 'wechat_dynamic', scene: 'invite_v2', timestamp: Date.now() } sessionStorage.setItem('shareParams', JSON.stringify(params)) // 生成动态路径链接 const shareUrl = `${window.location.origin}/share/${this.userId}` wx.shareTimeline({ link: shareUrl }) }

在SharePage.vue中，props能拿到uid，而sessionStorage能补全其他参数：

// SharePage.vue props: { uid: { type: String, required: true } }, created() { // 1. 从props拿uid（路径参数） this.userId = this.uid // 2. 从sessionStorage拿完整参数（覆盖props，确保一致性） const stored = sessionStorage.getItem('shareParams') if (stored) { try { const params = JSON.parse(stored) this.userId = params.uid // 强制以存储为准 this.source = params.source this.scene = params.scene sessionStorage.removeItem('shareParams') } catch (e) {} } }

这样，链接既美观（/share/123），又功能完整（所有参数可用）。我在某SaaS产品的客户案例分享模块中用过此方案，运营同学反馈“链接发给客户，显得更正规”。

3.3 路由复用与状态保持：避免“分享-返回-再分享”的参数污染

一个常被忽略的场景是：用户A分享链接给B，B点击后进入页面，然后B又点击“分享给C”。此时，如果B的页面没有清理掉A留下的参数，那么B分享出去的链接就会错误地带上A的uid。这就是路由复用导致的状态污染。

Vue Router提供了beforeRouteUpdate守卫来解决：

// views/SharePage.vue beforeRouteUpdate(to, from, next) { // 当路由参数变化时（比如从 /share/123 切到 /share/456） // 清理旧的sessionStorage参数，避免污染 sessionStorage.removeItem('shareParams') // 如果新路由有params，重新存一份 if (to.params.uid) { const newParams = { uid: to.params.uid, source: 'wechat_reshare', scene: 'reshare' } sessionStorage.setItem('shareParams', JSON.stringify(newParams)) } next() }

同时，在SharePage.vue的destroyed（Vue 2）或unmounted（Vue 3）钩子中，也要做一次兜底清理：

unmounted() { // 页面卸载时，确保sessionStorage干净 sessionStorage.removeItem('shareParams') }

这个细节，是区分“能用”和“好用”的关键。我在某在线教育平台的课程邀请功能中，就是因为漏了这一步，导致老师A的邀请码被学生B误传给了家长C，引发了一次小范围的数据归因混乱。

4. 微信JS-SDK的精准调用：从签名生成到分享事件的全链路控制

参数存储和路由适配解决了“数据在哪”的问题，而微信JS-SDK的调用，则决定了“数据能不能发出去”。很多团队卡在这一步：调用wx.config失败，提示invalid signature；或者wx.shareTimeline调用后，卡片标题还是默认的页面title。这背后，是微信对分享权限的严格管控——它要求每一次分享，都必须基于当前页面URL生成唯一的、有时效性的签名（signature），而这个签名，必须由后端服务计算并返回。

4.1 签名生成的“黄金四要素”：URL、nonceStr、timestamp、jsapi_ticket

微信JS-SDK的签名算法（SHA1）输入包含四个必填字段：

• jsapi_ticket：微信服务器签发的临时票据，有效期2小时，需后端定时刷新缓存。
• nonceStr：随机字符串，长度16位，每次调用必须不同，用于防重放。
• timestamp：当前时间戳（秒级），与jsapi_ticket生成时间差不能超过7200秒。
• url：当前页面的完整URL（注意：是微信客户端内看到的URL，不是你代码里写的）

其中，url是最容易出错的。很多人直接用window.location.href，但在微信中，这个值可能包含&from=singlemessage等微信私有参数，导致签名不匹配。正确做法是：在调用wx.config前，用window.location.origin + window.location.pathname + window.location.search拼接一个“纯净URL”：

// utils/wxConfig.js export async function initWxConfig() { try { // 1. 获取纯净URL（不含hash，不含微信私有参数） const pureUrl = window.location.origin + window.location.pathname + window.location.search // 2. 调用后端API获取签名配置 const res = await fetch('/api/wx/signature', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ url: pureUrl }) }) const config = await res.json() // 3. 初始化微信SDK wx.config({ debug: false, // 生产环境务必关闭 appId: config.appId, timestamp: config.timestamp, nonceStr: config.nonceStr, signature: config.signature, jsApiList: ['updateAppMessageShareData', 'updateTimelineShareData', 'onMenuShareTimeline'] }) } catch (e) { console.error('wx.config init failed', e) } }

后端生成签名的逻辑必须严格遵循微信文档，这里不展开。重点是：前端必须确保传给后端的url，与微信客户端最终展示的URL完全一致。我在某政务服务平台的办事指南分享模块中，就因为后端用了req.headers.referer来取URL，而微信客户端的referer是https://servicewechat.com/...，导致签名永远失败。后来改为前端主动上报纯净URL，问题迎刃而解。

4.2 分享数据的“双通道”设置：兼容新老API的稳健方案

微信在2020年后逐步废弃了onMenuShareTimeline等老接口，主推updateTimelineShareData。但现实是：大量存量微信版本（尤其是企业微信、部分安卓定制ROM）仍只支持老接口。因此，必须实现“双通道”：

// utils/shareManager.js export function setupShareData(shareData) { // 1. 新版API（微信7.0.12+） if (typeof wx.updateTimelineShareData === 'function') { wx.updateTimelineShareData({ title: shareData.title, link: shareData.link, imgUrl: shareData.imgUrl, success: () => console.log('updateTimelineShareData success'), fail: (err) => console.warn('updateTimelineShareData fail', err) }) } // 2. 老版API（兼容） if (typeof wx.onMenuShareTimeline === 'function') { wx.onMenuShareTimeline({ title: shareData.title, link: shareData.link, imgUrl: shareData.imgUrl, success: () => console.log('onMenuShareTimeline success'), cancel: () => console.log('onMenuShareTimeline cancel'), fail: (err) => console.warn('onMenuShareTimeline fail', err) }) } // 3. 针对“发送给朋友”的单独设置（微信要求） if (typeof wx.updateAppMessageShareData === 'function') { wx.updateAppMessageShareData({ title: shareData.title, link: shareData.link, imgUrl: shareData.imgUrl, desc: shareData.desc || shareData.title, success: () => console.log('updateAppMessageShareData success') }) } } // 使用示例 setupShareData({ title: `邀请好友一起学${courseName}`, link: buildShareUrl(this.userId, 'wechat_appmsg'), // 这里link必须是纯净URL imgUrl: this.courseCover, desc: `这门课太棒了，快和我一起学！` })

注意link字段：它必须是你最终要跳转的目标URL，且必须与wx.config中签名的url同源（协议、域名、端口一致）。如果link是https://other.com，而签名url是https://example.com，wx.config会直接报错。这也是为什么我们强调“纯净URL”的重要性——它既是签名依据，也是分享跳转的基准。

4.3 分享事件的“原子化”监听：捕获用户真实意图

仅仅设置分享数据还不够。我们需要知道用户是否真的完成了分享，以及分享给了谁（朋友圈 or 好友）。微信提供了success和cancel回调，但它们的触发时机并不精确。更可靠的方式是：在用户点击分享按钮时，就记录一次“分享意图”，并在success回调中确认“分享完成”。

// components/ShareButton.vue data() { return { shareIntentId: null // 每次点击生成唯一ID } }, methods: { handleShareClick() { // 1. 生成唯一意图ID this.shareIntentId = `intent_${Date.now()}_${Math.random().toString(36).substr(2, 9)}` // 2. 上报“意图”事件（可用于埋点） this.reportShareIntent(this.shareIntentId) // 3. 设置分享数据 setupShareData(this.getShareData()) }, reportShareIntent(id) { // 上报到埋点服务 fetch('/api/track', { method: 'POST', body: JSON.stringify({ event: 'share_intent', intent_id: id, page: this.$route.path, uid: this.userId }) }) }, onShareSuccess() { // 4. 分享成功后，上报“完成”事件，并关联intent_id if (this.shareIntentId) { fetch('/api/track', { method: 'POST', body: JSON.stringify({ event: 'share_success', intent_id: this.shareIntentId, share_to: 'timeline' // 或 'appmessage' }) }) } } }

在setupShareData的success回调里，调用this.onShareSuccess()。这样，后端就能通过intent_id把“意图”和“结果”串联起来，分析分享转化率。我在某知识付费平台的课程分销系统中，正是靠这套原子化埋点，精准识别出哪些老师的分享链接带来了真实付费，从而优化了佣金结算逻辑。

注意：微信的success回调并非100%可靠。实测发现，在iOS微信中，如果用户点击分享后立即切到其他App，success可能永远不会触发。因此，“意图”事件是必须的，它是归因分析的底线保障。

5. 实战排错手册：从“参数消失”到“卡片不显示”的12个高频问题与根因定位

再完美的方案，也会在真实环境中遇到各种“意外”。我把过去三年在十几个Vue微信项目中踩过的坑，浓缩成一份实战排错手册。这些问题不分先后，但每一个都曾让团队加班到凌晨。

5.1 问题1：分享卡片显示“网页可能暂时无法访问”，但页面本身能正常打开

根因：wx.config中的jsapi_ticket过期或签名错误，导致微信拒绝执行任何JS-SDK API。
排查链路：

1. 打开微信开发者工具（或在手机微信中开启“调试”），查看console是否有config:fail报错；
2. 如果有，检查后端返回的appId、timestamp、nonceStr是否与签名计算时使用的完全一致；
3. 特别检查timestamp——必须是秒级时间戳，且与微信服务器时间误差不能超过7200秒；
4. 用 微信JS-SDK签名工具 手动验证签名，输入后端返回的jsapi_ticket、nonceStr、timestamp和纯净URL，看是否匹配。
   修复：后端必须缓存jsapi_ticket，并在每次调用前检查其剩余有效期，不足30分钟则主动刷新。

5.2 问题2：卡片标题/描述/图片总是显示页面默认值，不显示updateTimelineShareData设置的内容

根因：wx.config未成功，或updateTimelineShareData调用时机错误（在wx.ready外调用）。
排查链路：

1. 确保wx.config调用后，必须在wx.ready回调中执行updateTimelineShareData；
2. 检查wx.ready是否被多次调用（比如在路由守卫中重复初始化）；
3. 查看微信调试工具Network面板，确认updateTimelineShareData请求是否发出；
4. 检查imgUrl是否为HTTPS绝对路径，且图片尺寸建议1200×630像素，大小不超过300KB。
   修复：封装一个safeUpdateShareData函数，内部用wx.ready包裹：

export function safeUpdateShareData(data) { wx.ready(() => { wx.updateTimelineShareData(data) }) wx.error((res) => { console.error('wx config error', res) }) }

5.3 问题3：iOS微信中，分享链接的hash参数丢失（如#uid=123变成#）

根因：iOS微信的WebView在处理history.pushState时，对hash的解析存在bug，特别是在location.replace后。
排查链路：

1. 在iOS设备上，用Safari调试远程Web Inspector，监控window.location.hash的变化；
2. 发现router.push后，hash被重置为空；
3. 检查Vue Router配置，是否启用了scrollBehavior并触发了window.scrollTo，间接影响hash。
   修复：强制在router.afterEach中恢复hash：

router.afterEach((to, from) => { if (to.hash && to.hash !== window.location.hash) { // iOS微信bug workaround setTimeout(() => { window.location.hash = to.hash }, 100) } })

5.4 问题4：Android微信中，分享链接的参数被截断（如#uid=123&source=wechat&scene=invite只剩#uid=123）

根因：URL总长度（含hash）超过微信的内部限制（实测约2000字符），微信会从末尾开始截断。
排查链路：

1. 在Android微信中，用alert(window.location.href.length)查看当前URL长度；
2. 如果超过1800，基本可以确定是长度问题；
3. 检查imgUrl是否为超长base64字符串，或title是否包含大量emoji。
   修复：压缩所有非必要字段。imgUrl必须用CDN短链；title控制在30字以内；desc用摘要代替全文；参数键名尽量缩写（uid代替user_id）。

5.5 问题5：用户点击分享链接后，页面白屏，Vue应用未启动

根因：window.__SHARE_PARAMS__预加载时，JSON.parse抛出异常，导致main.js后续代码中断。
排查链路：

1. 在main.js的preloadShareParams函数中，加console.log输出每一步；
2. 发现sessionStorage.getItem('shareParams')返回null或非法JSON；
3. 检查handleShare中是否在try/catch外调用了setItem。
   修复：所有getItem和JSON.parse必须包裹在try/catch中，且要有默认值兜底：

try { const raw = sessionStorage.getItem('shareParams') if (raw) { window.__SHARE_PARAMS__ = JSON.parse(raw) || {} } } catch (e) { console.warn('shareParams parse error, use empty object') window.__SHARE_PARAMS__ = {} }

5.6 问题6：同一台手机，A用户分享的链接，B用户点击后，参数却是A的

根因：sessionStorage未及时清理，或localStorage的share_latest_key被多个用户共用。
排查链路：

1. 在B用户手机上，打开微信调试工具，执行sessionStorage.getItem('shareParams')；
2. 发现返回的是A用户的参数；
3. 检查handleShare中是否遗漏了sessionStorage.removeItem。
   修复：在SharePage.vue的created中，读取后立即removeItem；在unmounted中再次removeItem；localStorage的key必须包含用户唯一标识（如share_${userId}_${Date.now()}）。

5.7 问题7：分享到朋友圈后，卡片显示正常，但点击跳转时参数丢失

根因：link字段设置错误。link必须是最终跳转的URL，且必须与wx.config签名的URL同源。
排查链路：

1. 在setupShareData中，console.log('share link:', shareData.link)；
2. 发现link是https://other.com/share?uid=123，而签名URL是https://example.com；
3. 微信会静默将link重写为签名URL的域名。
   修复：link必须是https://example.com/#uid=123或https://example.com/share/123，绝不能跨域。

5.8 问题8：Vue Routerhistory模式下，分享链接点击后，页面404

根因：后端服务器未配置history模式的fallback，无法将/share/123这样的路径重写到index.html。
排查链路：

1. 直接在浏览器地址栏输入https://example.com/share/123，看是否404；
2. 如果是，说明是后端配置问题；
3. Nginx需添加try_files $uri $uri/ /index.html;；Apache需启用mod_rewrite。
   修复：联系运维，按Vue Router官方文档配置服务器。

5.9 问题9：微信中，window.location.href返回的URL包含&from=xxx，导致签名失败

根因：微信客户端会在URL末尾追加私有参数，干扰签名计算。
排查链路：

1. console.log(window.location.href)，发现URL末尾有&from=singlemessage&isappinstalled=0；
2. 后端用这个URL生成签名，必然失败。
   修复：前端拼接纯净URL时，必须用window.location.origin + window.location.pathname + window.location.search，绝对不要用window.location.href。

5.10 问题10：wx.shareTimeline调用