可用邀请页可纯前端实现，但防刷、溯源、动态分享链接必须依赖后端或第三方sdk；需动态生成invite_code并持久化来源参数，服务端校验才有效防刷。

直接用 HTML + 少量 JS 就能做出可用的邀请好友页，不需要框架、不依赖后端也能跑通基础流程；但真要防刷、追踪来源、生成带参数的分享链接，必须配合服务端或第三方 SDK（比如微信 JS-SDK 或 Firebase Dynamic Links）。

怎么生成带 invite_code 的分享链接

用户点击“分享”时，不能只拼一个静态链接，得动态塞入当前用户的唯一标识（如 user_id 或 invite_code）。纯前端可临时用 localStorage 模拟，但不可靠——页面刷新就丢，且无法跨设备同步。

• 推荐做法：首次进入页面时，向后端请求一个专属 invite_code，存到 localStorage 并写进 URL（如 https://example.com?ref=abc123）
• 若无后端，可用 crypto.randomUUID() 生成临时码（仅限测试，无法关联真实用户）
• 微信内分享必须用 wx.updateAppMessageShareData() 重写分享卡片 title/link，否则 ?ref=xxx 会被微信清理

怎么识别并留存邀请来源

被邀请人打开链接时，URL 中的 ref、invite_code 等参数必须在页面加载初期就被捕获并持久化，否则后续注册/登录时就丢了。

Wechat HTML Publisher

直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

下载

• 解析 URL 用 new URL(window.location.href).searchParams.get('ref')，别用正则硬拆
• 存来源推荐用 localStorage.setItem('invite_ref', ref)，比 cookie 更易读写
• 注意：iOS Safari 的隐私模式下 localStorage 可能抛错，需加 try/catch
• 如果用户先点链接、再跳转到登录页，记得把 ref 作为隐藏字段传过去（如表单里放 <input type="hidden" name="ref" value="xxx">）

怎么防止用户手动改 URL 刷邀请奖励

前端一切校验都可绕过，ref 参数伪造成本几乎为零。真正有效的防刷只能靠服务端完成。

• 前端只做体验优化：比如检测到 ref 存在，就显示“你是由 XXX 邀请来的”，但不直接发奖励
• 注册接口必须携带 ref 字段，由后端验证该码是否有效、未被使用、对应用户是否存在
• 常见翻车点：后端没校验 ref 是否属于“已注册用户”，导致自己邀请自己也生效
• 更严场景（如微信小程序），需结合 unionid 或 openid 做双因子绑定

最常被忽略的是分享渠道适配——微博、QQ、微信内置浏览器对 URL 参数的处理逻辑完全不同，有的会自动截断，有的强制跳转，有的禁止带参跳转。别只在 Chrome 里测完就上线。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！