主题
登录方式改造 · 产品方案
版本：v1.0 ｜ 最后更新：2026-07-11 适用：wallet-server（后端）/ wallet-pc（Web 前端）/ ios（App） 配套：
技术方案.md、登录方式原型.html一句话目标：在不砍掉现有 Email 登录、不劝退 Web2 小白的前提下，补齐欧美用户习惯的 Google / Apple 一键登录，并为 Crypto 老用户增量加一个「Connect Wallet」入口——用最低成本让登录页既好用又"够 Web3"。
0. 核心结论（先看这里）
- Email 登录不能砍，是资产不是包袱。 产品面向的是"钱包+卡"的消费支付场景，主力是 Web2 习惯的普通用户。行业趋势恰恰是把 Web3 做得越来越像 Web2（社交/邮箱登录 + 后台自动建钱包），而不是反过来抬高门槛。
- Google / Apple 登录要加，优先级最高（P0）。
- Apple 近乎强制：iOS App 只要提供了任意第三方社交登录（如 Google），App Store 审核规则 4.8 就要求你必须同时提供「Sign in with Apple」，否则审核被拒。你有 iOS App → 一旦上 Google 就必须上 Apple。
- Google 显著降转化门槛：欧美用户默认用 Google 账号一键登录，少填邮箱、免记密码、免收验证码，注册流失明显下降。
- Web3 登录（Connect Wallet）要加，但只作"可选入口"，不强制（P1）。 给 Crypto 老用户留一扇门（用自己的 MetaMask / OKX / WalletConnect 签名即可进），但绝不强制所有人用助记词/钱包——那会直接劝退你的 Web2 主力用户，转化率会掉。
- "Web3 风格" ≠ "高门槛"。 真正的 Web3 化不是让用户去背助记词，而是：① 登录页出现钱包入口和链的品牌感（现在登录页已有 BTC/ETH/USDT 图标带，方向对了）；② 后台把托管钱包做扎实。不要为了"看起来 Web3"牺牲易用性。
- 一个绕不开的产品约束：注册必须绑定"代理/邀请码"。 现有 Email 注册强制填代理码（代理分佣体系的根基）。Google/Apple/钱包这些"一键登录"的新用户没有地方填邀请码——必须设计"首次登录补全邀请码"这一步，否则要么破坏代理归属，要么放进来一批无归属用户。这是本次改造最容易被忽略、但必须先拍板的点（详见 §4）。
- 落地顺序：先 Google + Apple（覆盖 90% 的价值），再 Connect Wallet，最后（可选）评估把 Email 钱包升级为成熟嵌入式钱包方案（Privy / Web3Auth）。不建议一次全上。
1. 先认清现状：你现在在哪
| 维度 | 现状 | 含义 |
|---|---|---|
| 登录方式 | 仅 Email（邮箱+密码 / 邮箱+验证码两种） | 单一入口，欧美用户少了"一键登录"，Crypto 用户没有钱包入口 |
| 注册约束 | 必须填代理/邀请码 | 任何新登录方式都要解决"邀请码从哪来" |
| 钱包托管 | 私钥不在本系统，托管在外部 Pay Gateway；本系统只存余额账本 | 对用户是托管式——用户无需管私钥，本身就是"Web2 体验的 Web3 产品" |
| 二次验证 | 已有 TOTP 2FA（Google Authenticator） | 新登录方式要和 2FA 兼容 |
| 登录页风格 | 已是「Web3 ↔ 传统金融」桥接品牌，主色 #2b5fff，带 BTC/ETH/USDT/USDC 等链图标 | 视觉上已经"半 Web3"，缺的是钱包登录这个功能入口 |
| 密码存储 | MD5 + 盐 | 偏弱，建议借这次改造升级为 bcrypt（详见技术方案） |
关键洞察：你的产品从架构上本来就是"托管钱包 + 卡"，也就是当今最主流的 Web3 消费级形态（用户无感、平台托管、体验等于 Web2）。所以你缺的不是"变成 Web3"，而是"补登录入口"：给欧美用户 Google/Apple，给 Crypto 用户 Connect Wallet。
2. Web3 行业登录方式全景（按门槛从低到高）
给你一张"选型地图"，看清楚每种方式是什么、谁在用、适不适合你：
| # | 登录方式 | 一句话 | 门槛 | 代表方案 | 适合你吗 |
|---|---|---|---|---|---|
| 1 | 社交/邮箱登录 + 嵌入式钱包 | Email/Google/Apple 登录，系统后台自动建钱包，用户无感 | 极低 | Privy、Web3Auth、Magic、Dynamic | ✅ 你现在就是这个方向（钱包托管在 Pay Gateway） |
| 2 | Google / Apple 一键登录 | 用现有 Google/Apple 账号登录，免注册免密码 | 极低 | Google Identity、Sign in with Apple | ✅ P0 必做（欧美刚需 + iOS 合规） |
| 3 | Passkey / 账户抽象（AA, ERC-4337） | 指纹/FaceID 当钥匙，可免 Gas、社交恢复 | 低 | Coinbase Smart Wallet、Safe | 🔶 前沿，P2 观望 |
| 4 | 钱包签名登录（SIWE / Sign-In with Ethereum） | 点「Connect Wallet」→ MetaMask 弹窗签名验证 | 中高（需已有钱包） | SIWE、RainbowKit | ✅ P1 增量做（给 Crypto 老用户留门） |
| 5 | WalletConnect 协议 | 扫码把手机钱包连到网页 | 中高 | WalletConnect v2 | ✅ 和 #4 配套一起做 |
结论：你的主战场是 #1 + #2（低门槛、覆盖绝大多数用户），#4/#5 作为增量入口照顾 Crypto 老用户，#3 观望。
3. 是否支持 Google / Apple？—— 要，且是本次最高优先级
3.1 为什么要做
- 欧美用户的默认习惯：Google 账号一键登录是欧美 App 的标配，"用 Google 继续"比"填邮箱→等验证码→设密码"少 3~4 步，注册转化率显著更高。
- Apple 是 iOS 上架的硬门槛：App Store 审核规则 4.8——只要 App 提供了第三方登录（Google/Facebook 等），就必须同时提供 Sign in with Apple。你有 iOS App，一旦上 Google，Apple 就是强制项，不做审核过不了。
- 安全与信任：OAuth 由 Google/Apple 校验身份，减少弱密码、撞库风险；Apple 还提供"隐藏邮箱"（中继邮箱），对隐私敏感用户友好。
3.2 落地范围
| 平台 | Apple | |
|---|---|---|
| iOS App | ✅ 建议 | ✅ 强制（App Store 4.8） |
| Web (wallet-pc) | ✅ 建议 | ✅ 建议（Web 上 Apple 非强制，但体验统一更好） |
| Android（若有） | ✅ 建议 | 🔶 可选 |
3.3 交互原则
- Email 仍是"主入口"，Google/Apple 作为"或"的快捷方式，放在邮箱框下方（"—— 或 ——"分隔），符合欧美用户扫视习惯。
- 首次社交登录 = 注册：若该 Google/Apple 邮箱在系统里不存在，走"首次注册"流程，在此补填邀请码（见 §4）。
- 邮箱撞库自动合并：若社交登录返回的邮箱和已有 Email 账号相同，自动绑定到同一账号（同一个人，不该产生两个钱包）。
4. ⚠️ 绕不开的约束：一键登录用户的"邀请码"怎么办
这是本次改造最关键、最容易漏的产品决策。现有注册强制填代理/邀请码（代理分佣的根基），但 Google/Apple/钱包这些"一键登录"天然没有填码环节。三种处理策略，请拍板选一：
| 方案 | 做法 | 优点 | 缺点 | 建议 |
|---|---|---|---|---|
| A. 首次登录补填码（推荐） | 社交/钱包首次登录成功后，若是新用户，插入一个"完善注册"页让其填邀请码才算注册完成 | 完整保留代理归属体系；风险可控 | 多一步，轻微增加流失 | ⭐ 推荐——代理分佣是你的商业根基，不能破 |
| B. 落默认代理 | 无邀请码的社交/钱包用户，自动挂到一个"平台默认代理" | 零摩擦，转化最高 | 破坏"谁邀请谁分佣"的归属；默认代理会吃走这部分佣金 | 仅当你有明确"直客默认归属"策略时用 |
| C. 带参链接透传 | 通过带邀请码的深链（?invite=xxx）进来，社交登录时自动带上 | 无感、归属准确 | 只覆盖"从代理链接进来"的用户；直接搜 App 的用户仍需 A | 与 A 组合最佳 |
推荐组合：C（能带就带）+ A（带不到就补填）。既不破坏代理归属，又把摩擦降到最低。
5. 是否改造成 Web3 风格？—— 保留 Email，增量加「Connect Wallet」，不强制
5.1 结论
不建议为了"看起来 Web3"而砍 Email 或强推助记词。 正确做法是在现有登录页增量加一个「Connect Wallet」入口：
- Crypto 老用户点「Connect Wallet」→ MetaMask / OKX / WalletConnect 弹窗 → 签名 → 进入。不用邮箱、不用密码。
- Web2 小白继续用 Email / Google / Apple，完全不受影响。
5.2 为什么不激进 Web3 化
| 如果强制钱包/助记词 | 后果 |
|---|---|
| 要求所有人有 MetaMask | 90% 的欧美消费用户没有 → 直接流失 |
| 要求抄写/保管助记词 | 小白最怕这个 → 注册漏斗大幅跳出 |
| 去掉 Email | 无法找回、无法收 3DS/风控邮件 → 卡业务合规和触达都出问题 |
5.3 Web3 化的"正确姿势"（不牺牲易用性）
- 登录入口层：加 Connect Wallet（本次做）。
- 视觉品牌层：登录页已有链图标带（BTC/ETH/USDT…），保持"链上资产 + 卡"的桥接叙事即可。
- 钱包体验层（中长期，可选）：现有 Email 钱包托管在 Pay Gateway。若未来想更"正宗 Web3"（用户可自持、可链上验证），可评估接入 Privy / Web3Auth 这类嵌入式钱包——让"Email 登录"也能生成"用户自己的链上钱包"，既保留低门槛又更去中心化。这是 P2 的大改，本次不做，先留坑。
6. 推荐落地路线（分期）
| 期 | 内容 | 价值 | 复杂度 | 依赖 |
|---|---|---|---|---|
| P0（本期） | Google 登录 + Apple 登录（Web + iOS）；打通"首次登录补填邀请码"（§4 方案 C+A） | 覆盖 90% 价值：欧美转化↑ + iOS 合规过审 | 中 | 需 Google/Apple 开发者账号、后端新增 OAuth 校验接口 |
| P1 | Connect Wallet（SIWE 签名登录 + WalletConnect），照顾 Crypto 老用户 | 品牌"够 Web3" + 老用户可进 | 中 | 前端接 wagmi/RainbowKit，后端加 nonce + 验签接口 |
| P1.5（顺带） | 密码哈希 MD5 → bcrypt 平滑升级（登录时静默重算） | 安全加固 | 低 | 见技术方案 |
| P2（可选/观望） | 评估嵌入式钱包（Privy/Web3Auth）替换现有 Email 钱包托管；Passkey/AA 观望 | 更去中心化、更"正宗 Web3" | 高 | 涉及钱包托管架构，需与 Pay Gateway 协同 |
7. 一句话总结
你现在的 Email 方向没错，产品本质已经是"托管钱包+卡"的主流 Web3 消费形态。缺的只是两个入口：给欧美用户 Google/Apple（P0，且 Apple 是 iOS 上架硬要求），给 Crypto 老用户 Connect Wallet（P1）。别砍 Email、别强推助记词——让用户感觉不到自己在用 Web3，才是最好的 Web3 产品。 唯一必须先拍板的产品决策是：一键登录用户的邀请码怎么给（§4）。