你应该添加推荐计划吗？

Sushi SaaS 提供推荐功能的技术基础，而不是完整联盟营销方案。它默认关闭。启用后，系统可以把新账户归因给推荐者，并在付款后记录 pending 奖励；它不会验证联盟成员、自动转账、发放积分或把打款标记为完成。

默认用户旅程

1. 登录用户创建短邀请码（通常为八位）并分享 /i/<code>。
2. 访客打开链接，应用将推荐者 UUID 写入有效期 30 天的 ref cookie，然后跳转首页。
3. 访客登录后，客户端把 cookie 提交到归因接口。
4. Service 只认领一次推荐者；系统拒绝自我推荐，并让并发重试收敛到首次成功归因。
5. 符合条件的已支付订单创建一条 pending 佣金；数据库唯一约束使 webhook 重放无害。

用户可在现有 my-invites 页面查看邀请链接和汇总。运营人员可在管理后台 affiliates 页面检查记录，但该页面只读，并不是打款工作流。

默认示例取 5,000 个最小货币单位与已付金额 20% 中较大者。对于两位小数的美元收费，5,000 代表 50 美元。这只是示例，不是推荐佣金比例。

配置见 7580470 的 src/config/affiliate.ts，编排逻辑见 src/services/affiliate.ts。

先选择计划，再选择代码

佣金计算已支持纯固定、纯比例、取较大值和相加。归因逻辑目前不会根据 AttributionModel 切换，因此应把首次触达视为已实现的契约。

仍需制定的政策

• 哪些购买符合条件，pending 奖励何时可打款？
• 退款、争议、取消或账户擦除后如何处理？
• 使用哪种货币和最小单位规则？
• 员工、现有客户或同一家庭是否可以参与？
• 在服务地区，推荐 cookie 是否需要征得同意？
• 运营如何调查滥用并修正记录，同时保留审计线索？

Stripe 退款处理可取消仍为 pending 的奖励，但已完成打款的追回并未实现。政策和失败路径完成前，不要自动移动资金。

安全启用

1. 先配置并测试 Stripe 计费。
2. 替换 src/config/affiliate.ts 中的示例窗口和奖励数值。
3. 在开启功能前完成打款或积分工作流及其管理操作。
4. 测试匿名访问 → 注册/登录 → 首次归因 → 付款 → webhook 重放 → 退款。
5. 测试自我推荐、两个竞争链接、cookie 过期和并发事件。

具体配置与验证步骤见配置推荐与联盟奖励，当前审核界面见管理后台页面与操作。