纯HTML+JS裂变页通过URL参数（如ref=abc123）提取邀请ID并存入localStorage，用于后续行为上报；需配合后端校验与归因，前端仅作线索传递，不可依赖其渲染关键提示或替代服务端逻辑。
怎么用纯 HTML + JS 实现带分享追踪的裂变页
纯静态 HTML 页无法自动记录谁邀请了谁，必须配合后端或第三方服务。但你可以用 URL 参数 + localStorage 在前端完成基础关系绑定和展示逻辑，适合 MVP 验证或轻量活动。
核心思路：用户点击分享链接时带上 ref=abc123，落地页读取该参数存入 localStorage；后续所有行为（如领券、提交表单）都附带这个 ref 上报给后端。
- 分享链接示例：
https://example.com/act?ref=uid789，其中uid789是邀请人 ID - 页面加载时用
new URLSearchParams(window.location.search).get('ref')提取参数 - 存入
localStorage.setItem('referrer', ref)，避免刷新丢失 - 注意：iOS Safari 的无痕模式会禁用
localStorage，需 fallback 到sessionStorage或直接丢弃（不强依赖）
微信里点开裂变页为啥拿不到 URL 参数
微信内置浏览器对 URL 参数有“净化”行为，尤其在从聊天窗口跳转、公众号菜单、小程序转发等路径下，location.search 可能被清空或重写。
这不是 HTML 本身的问题，而是微信的限制策略。你不能靠前端完全规避，但可以降低影响：
立即学习“前端免费学习笔记（深入）”；
- 所有分享必须走
JS-SDK的updateAppMessageShareData和updateTimelineShareData，把ref写进shareUrl字段（不是靠用户手动复制链接） - 首次进入页面时若没拿到
ref，可尝试从document.referrer解析（仅限同域，且微信常为空） - 更稳妥的做法：后端生成带签名的短链（如
https://a.co/r/xyz），由服务端 302 跳转并注入ref参数，绕过微信前端截断
localStorage 存 ref 会被用户清除怎么办
会。而且清除后，后续行为就丢失邀请关系。但这是用户主动行为，你无法阻止，只能减少依赖层级。
关键不是“存不存”，而是“什么时候用”：
- 只在用户触发关键动作（如点击“立即参与”按钮）时，才从
localStorage读一次referrer，拼进请求体发给后端 - 不要在页面渲染阶段就依赖它显示“您已被 XXX 邀请”——那容易出错或被伪造
- 后端收到请求后，应校验
ref是否真实存在、是否未被使用过、是否在有效期内，而不是前端传啥就认啥 - 如果业务允许，可在用户登录后，用账号 ID 替换掉临时
ref，实现关系归一
为什么不用 document.cookie 替代 localStorage
可以，但没必要，且更麻烦。
cookie 在跨域、HTTPS 混合、Safari ITP 等场景下失效更频繁；而裂变页多数是独立域名或子路径，localStorage 范围更可控。
-
cookie需要设置domain和path，稍有不慎就写不进或读不出 - 每次 HTTP 请求都会自动携带 cookie，增加请求头体积，对图片、字体等静态资源也无效
-
localStorage容量更大（通常 5–10MB），存一个字符串绰绰有余 - 真正要注意的是：别用
localStorage存敏感信息（如用户手机号），它可被任意脚本读取
最易被忽略的一点：裂变效果最终靠后端数据归因，前端只是“尽力而为”地传递线索。别在 HTML 里写死逻辑，比如用 if (ref) { showInviteBanner() } 这类判断——它会让运营无法动态开关入口，也不利于 AB 测试。把决策权交给后端返回的 JSON 配置更可靠。
