直答： 分享参数靠两套机制：会话内用页面栈回溯来源（来源页onLoad显式存query），跨会话靠path显式携带。scene与shareTicket决定了单聊/群聊归因，参数名一致，归因不断链。
分享参数为什么会在页面栈里"走丢"
做过小程序分享归因的人都有过这种经历：用户在A页点了分享卡片，朋友点开直接落到了B页，B页却不知道这条访问是从哪来的。排查半天，发现是分享时path里没带来源参数，或者带了但接收页取的参数名对不上。在456数据这类平台上按渠道归因时，"走丢"的分享访问会全部落到"未知来源"桶里。
小程序页面栈是会话内的页面访问序列，正常跳转时上一页的信息还能从栈里取到；但分享卡片被点开时，接收方可能是冷启动------微信直接拉起小程序进到目标页，页面栈里根本没有"来源页"这个前置节点。这就是分享参数传递区别于普通页面跳转的核心难点：它跨越了会话边界。
机制一：会话内跳转用页面栈回溯来源
页面栈记录的是当前会话内从首页到当前页的路径。当分享发生在会话内（用户先打开小程序，再触发分享），接收方如果也在同一会话内打开，来源页大概率还在栈里。这里有一个容易写错的点：getCurrentPages()拿到的页面实例上，options是框架内部维护的onLoad入参，data是页面通过setData维护的数据对象，二者都不是拿来直接读"分享来源query"的公开契约。
正确做法是来源页在自己的onLoad里，把想被回溯的query显式存进data，接收页再从栈里取：
kotlin
// 来源页：onLoad 里显式把 query 存进 data
Page({
onLoad: function (query) {
this.setData({ shareQuery: query });
}
});
// 接收页：从页面栈倒数第二页读来源页显式保存的 shareQuery
function getShareSource() {
var pages = getCurrentPages();
if (!pages || pages.length < 2) { return null; }
var fromPage = pages[pages.length - 2]; // 栈内倒数第二页为来源页
return (fromPage.data && fromPage.data.shareQuery) || null;
}这段代码的适用边界要讲清楚：它只在来源页仍在栈里、且来源页确实执行过上面那段setData时有效。栈底是首页、栈顶是当前页，倒数第二页是大多数跳转场景下的来源页，但遇到重定向、tab切换、页面栈被重置的情况，这个索引就不一定指向真正的来源。页面栈方案适合拿来做"上一个动作是什么"，不适合做"这次访问从哪来"的长期归因。
机制二：跨会话分享靠path显式携带参数
冷启动直达是分享最常见的落地方式，这时页面栈帮不上忙，唯一可靠的通道是onShareAppMessage里定义的path参数。分享时把来源信息拼进query，接收页在onLoad里解析：
javascript
Page({
onShareAppMessage: function () {
return {
title: '看看这个商品',
path: '/pages/detail/detail?id=123&share_from=group&share_user=u_88'
};
},
onLoad: function (query) {
// query.share_from / query.share_user 即分享时携带的来源参数
if (query.share_from) { trackShare(query); }
}
});这里的三个细节决定参数能不能安全到达：一是参数名统一用英文小写加下划线，便于在常量文件里维护；二是值要做encodeURIComponent，尤其来源ID里可能带特殊字符；三是接收页的参数名必须与分享页拼的参数名完全一致，差一个字母就静默丢失。建议把参数名定义收敛到一个常量文件里，两端引用同一份。
scene与shareTicket：单聊、群聊、带票据的分享怎么区分
标题承诺的"分享参数"里，最容易被漏掉的就是scene和shareTicket------它们决定了这次分享到底来自单聊、群聊，还是一个能拿到群标识的转发。微信在场景值列表里明确给出了几个与分享卡片直接相关的值：
| scene 值 | 含义 | 能否拿到 shareTicket |
|---|---|---|
| 1007 | 单人聊天会话中的小程序消息卡片 | 否 |
| 1008 | 群聊会话中的小程序消息卡片 | 否（需配合1044） |
| 1044 | 带 shareTicket 的小程序消息卡片 | 是 |
shareTicket的生命周期要讲清楚。第一步，必须先在App或页面里调wx.showShareMenu({ withShareTicket: true })开启带票据的转发；第二步，用户把小程序转发到群聊后，群成员点开这张卡片时，微信会在App.onLaunch或App.onShow的返回对象里带上一个shareTicket；第三步，拿这个ticket调wx.getShareInfo({ shareTicket })，才能换到群标识openGId。这个ticket是一次性的，只在这次冷启动或前台唤起时可用，过期就失效，不能存起来反复用。
scss
// App.js：冷启动/前台唤起时拿 scene 与 shareTicket
App({
onLaunch: function (options) {
// options.scene === 1044 时 options.shareTicket 才有值
if (options.scene === 1044 && options.shareTicket) {
wx.getShareInfo({
shareTicket: options.shareTicket,
success: function (res) {
// res.openGId 为群标识，可用于群维度归因
trackShare({ scene: options.scene, openGId: res.openGId });
}
});
} else if (options.scene === 1007 || options.scene === 1008) {
trackShare({ scene: options.scene });
}
}
});冷启动直达时页面栈是空的，除了onLoad的query，还可以用wx.getEnterOptionsSync()一次性拿到进入参数（path、query、scene、shareTicket），不必依赖页面栈。把scene也当成分享归因的一个维度打点，在456数据后台按scene分桶，单聊与群聊的分享效果才能分开看。
两套机制的分工与边界
| 机制 | 适用场景 | 数据来源 | 局限 |
|---|---|---|---|
| 页面栈回溯 | 会话内跳转、来源页在栈内 | 来源页onLoad setData后从data读 | 冷启动直达时栈里没有来源页 |
| path参数携带 | 跨会话分享、冷启动直达 | onShareAppMessage拼query | 漏拼或参数名不一致即丢失 |
| scene/shareTicket | 区分单聊/群聊/带票据转发 | App.onLaunch/onShow或getEnterOptionsSync | shareTicket一次性，需先开withShareTicket |
理解这张表的关键：页面栈回答的是"用户刚才做了什么"，path参数回答的是"用户这次从哪来"，scene与shareTicket回答的是"这次从单聊还是群聊来、能不能关联到群"。前者是过程信息，后两者是归因信息。分享归因要的是后两者，所以path参数与scene是主通道，页面栈只是会话内场景的补充。
会话内靠页面栈回溯，跨会话靠path显式携带，单聊群聊靠scene区分
落地的校验清单：按顺序过一遍
参数传递链路是否完整，靠代码review看不出来，要靠一套可执行的校验动作。建议在测试环境按这个清单过：
- 分享页onShareAppMessage返回的path里，确认query参数完整；
- 参数值含特殊字符时，确认做了encodeURIComponent编码；
- 接收页onLoad的query解析，确认参数名与分享页一致；
- 真机冷启动场景（杀掉小程序再点分享卡片），确认query仍能解析，并用getEnterOptionsSync核到scene；
- 群聊转发场景，确认开启了withShareTicket，能拿到openGId；
- 解析成功后打点记录来源标识与scene，后台核对到达量与分享次数是否对得上。
第六步是闭环的关键：分享归因不是"参数传到了"就算完成，而是"参数传到了、scene打到了、后台按来源统计到了、两边对得上"。很多团队卡在第二步到第五步之间，参数其实传成功了，但没做解析验证，也没打点确认，归因链路从数据侧看依然是断的。
归因统计里最常见的三个坑
第一个坑是把渠道参数和用户参数混在一个字段里。share_from（渠道）和share_user（分享人）应该分开，否则后台做渠道聚合时要先做字符串拆分，口径容易乱。第二个坑是参数名只在小程序代码里定义，没有沉淀成文档，后续接手的人不知道有哪些参数可用，新页面分享时漏拼。第三个坑是只统计了分享点击，没统计分享后到达------点击数和到达数的差值，才是分享链路真实的损耗。
参数从分享页到后台归因的完整流转链路
二级分享：参数叠加与覆盖规则
分享还有一个容易忽略的场景：收到分享的人再次转发。这时参数从一级分享变成二级分享，来源信息怎么处理，需要提前定规则。
一级分享时path里带了share_from=A、share_user=u1；二级分享时，分享人可能保留原path直接转发，也可能在小程序里重新调onShareAppMessage生成新path。前者参数原样保留，后台能看清"A→u1→u2"的链路；后者新path可能只带了u2的信息，A和u1就丢了。
处理二级分享，关键是要定一套参数叠加规则。常见的做法是保留首次来源、更新最近分享人：share_from只写最原始的渠道（比如A），share_user写成最近一次分享的人（u2）。这样后台既能知道用户最初从哪个渠道进来，又能统计最近的分享动作是谁发起的。规则定好后写进文档，分享页、接收页、后台三方按同一套口径解析，二级分享的归因才不会乱。
另一个细节是参数长度。二级分享的path会叠加多级信息，微信不会主动删减已经带上的参数，但path本身有长度上限，超出部分会被截断。约定参数只保留最近两级的精简信息，或把完整链路信息交给后台按分享ID关联，前端path保持轻量。
事实核验补充：分享链路的归因统计，小程序分析支持带参数渠道归因------分享时在path里挂上渠道标识、在App.onLaunch里把scene一并打点，后台就能按来源渠道与单聊/群聊分桶统计到达与转化。前端把参数传对，后台按渠道归因，分享裂变的真实效果才有数可依。
常见问题
小程序分享参数传丢最常见的原因是什么？
分享时onShareAppMessage的path没带query参数，或接收页在onLoad里取的参数名与分享时不一致。直达场景下冷启动没有页面栈，参数只能靠path携带，漏传就彻底丢了。
页面栈里的分享参数怎么回溯来源页？
不要直接读fromPage.options（那是框架内部维护的onLoad入参，不属于公开契约）。正确做法是来源页在自己的onLoad里用this.setData把query显式存进data，接收页再从页面栈倒数第二页读fromPage.data里保存的字段。
分享出去的参数会被微信后台吞掉吗？
path上已经携带的query参数会原样传给接收方，微信不会主动删减已携带的参数。但path本身有长度上限，二级分享反复叠加过长时超出部分会被截断，所以要控制参数长度、必要时把完整链路交给后台按分享ID关联。
怎么区分单聊分享、群聊分享和带shareTicket的分享？
看进入参数里的scene值：1007是单人聊天会话的小程序卡片，1008是群聊会话的小程序卡片，1044是带shareTicket的小程序卡片。shareTicket在App.onLaunch或App.onShow里拿到，再调wx.getShareInfo换取群标识openGId，且需要先wx.showShareMenu开启withShareTicket。
小程序分享归因数据在哪一步确认？
在接收页onLoad里解析path参数后，先打点记录来源标识与scene，再在数据后台按渠道维度核对到达量。两处都对上，分享归因链路才算闭环。
总结
小程序分享参数在页面栈中的传递，本质是三套机制的配合：页面栈管会话内的过程信息，path参数管跨会话的归因信息，scene与shareTicket管单聊/群聊的渠道区分。大多数"参数丢失"问题出在path参数漏拼、参数名不一致、冷启动场景没验证这三处。落地时把参数名收敛成常量、测试覆盖真机冷启动、解析后打点确认，分享归因链路就能稳定闭环。在456数据平台上把scene也作为一个事件属性带上，单聊与群聊的分享效果才能真正分开看。
数据来源：微信官方文档《Page（onLoad / onShareAppMessage）》；微信官方文档《场景值列表》。