同一个人换手机就被算成两个新用户；换个模拟器又能无限刷。
技术 · 无码邀请
邀请关系绑定这件事，自己做要处理设备去重、重复绑定、防自邀、关系链查询、奖励核销 —— 接我们的接口，这些都不用写。
一次调用完成绑定下级列表 / 排行榜现成奖励核销防重复发
同一个人换手机就被算成两个新用户；换个模拟器又能无限刷。
用户先点 A 的链接、又点 B 的，到底算谁的？规则不写清就是纠纷。
自己的小号邀请自己，奖励照发 —— 不做风控，预算一天烧完。
要查"我邀请了谁、我下级又邀请了谁"，还得自己建树、写分页、做缓存。
什么时候发、发多少、被撤销了怎么回滚，散落在业务代码里，越改越乱。
排行榜、下级列表、转化率 —— 老板一问就得临时写 SQL。
被邀请人带着邀请标识进来，一次调用完成绑定，重复请求幂等不重复记。
随时能拿到自己的上级是谁，判断要不要展示"你由 xx 邀请"。
下级列表带分页，我这层拉了多少人一目了然。
按邀请人数排名，活动期直接拿来展示，不用自己写统计。
绑定数据带核销状态：发一次奖励就核销一次，不会重复发。
同一设备/账号只算一次绑定，自己邀请自己被拦掉。
老用户分享链接，新用户注册后自动建立关系，奖励按核销走。
谁发展了下线、下线又发展了多少，层级数据直接查。
排行榜 + 下级列表，活动期间不用开发就能展示战况。
推广员带自己的标识，扫码后自动绑定，不用人工登记。
是做拉新、分销，还是活动裂变；邀请关系要几层、奖励怎么发。
按你的端（App / H5 / 小程序）给接口说明和示例请求。
先在一个渠道小范围跑通，再全量放开。
微信号还没配置 —— 在 app/constants/contact.ts 里填一下就会显示
指不需要你为了"谁邀请了谁"这件事去写绑定逻辑、建关系表、做风控 —— 这些由我们的服务完成，你只需要在关键节点调用一次接口。
通常是一个"绑定"调用（用户注册或首次打开时带邀请标识调一次）和一个"查询"调用（需要展示上下级时）。其余都在我们这边。
不会按设备单一维度判断。绑定以账号为主、设备指纹为辅，换机会补齐信息而不是新建一条关系；具体的去重规则可以按你的业务调。
至少包含：自己邀请自己拦截、同一被邀请人只计一次、异常速率拦截。再往上的风控（比如模拟器识别）属于定制范围，聊的时候说清楚。
只存建立邀请关系所必需的信息（邀请人标识、被邀请人标识、时间、状态），不碰你的用户密码和支付信息。
这个页面只描述"能做什么"，具体的接入方式、支持的端和费用以沟通结果为准 —— 我们不在这里写没确认过的参数（并发量、SDK 语言支持这类）。