U8 Chat 2.0 · 登录密码（密码登录 / 设置密码 / 忘记密码）产品需求文档（PRD）

本 PRD 做了什么：这个功能的界面工作量不大（登录页多一个入口、设置里多一行），真正要写清的是三件事 —— ① 密码与验证码是什么关系（两条平行的登录方式，不是两步验证）；② 忘记密码怎么自救（本期没有客服）；③ 密码的规则、错误次数、锁定，以及重置后的设备处置。分别落在第三、七、八章。
与既有交付物的关系：验证码参数（5 位 / 5 分钟 / 30s 重发 / 错误 5 次锁 24 小时）与「修改手机号」统一；系统通知由官方账号「U8 Chat」承载、验证码走哪条通道、新设备登录通知全部沿用「设备管理」6.9.1，本 PRD 不重新定义。
演示页怎么用：index.html 共 18 屏，左栏可按「核心路径（P0）/ 规则与状态（P1）」筛屏；手机屏上的虚线框就是可点的地方，鼠标悬停会显示它跳到哪一屏。
本次范围（2026-09-23 产品明确）：只做 密码登录 + 忘记密码；密码登录的前提＝手机号已注册登录、且用户自己设置过密码（没有默认密码）。已经开发完成的页面（登录验证码页、手机号位数校验弹窗）不再画；与本次无关的元素（网络诊断入口、国家编码能否点等）既不做标注也不做解释（开发有疑问产品会自己解答）。演示页说明栏只写本次新增的内容。
演示版与设计稿的关系（2026-09-23 产品澄清，重要）：本演示与 PRD 都是「UI 设计之前的输入」 —— 作用是告诉 UI「这个功能有哪些流程、有哪些页面、从哪儿进」，并给出每个页面的规则与文案建议。已有的 Figma 画板（登录页、我的-隐私和安全）照做；还没画的页面由本演示给出建议稿。最终视觉以 UI 设计为准，因此按钮摆放、间距一类版式细节不作为评审与验收项。

---

一、背景与目标

1.1 背景

U8 Chat 的账号体系里手机号就是账号：注册、登录、加好友、找回都围绕它。原本唯一的登录方式是「手机号 + 验证码」，并且新用户手机首次登录即完成注册 —— 没有独立的注册流程，用户在这一步看不到「注册」两个字。这套逻辑本次保持不变。

本次新增的是一条平行的登录方式：登录密码。

• 定位：手机不在身边 / 收不到验证码时的备用入口；常用设备上更快的登录路径；服务端侧多一道不依赖短信通道的凭证。
• 形态：密码是后设置的、可选的（产品原话：「密码是后设置的」）—— 不强制、不弹窗打断，入口放在「我的 → 隐私和安全 → 登录密码」，由用户在已登录状态下自己设。

1.2 现状问题（本次要解决的）

1.3 目标

业务目标

• 在不改变账号体系、不增加注册流程的前提下，把「收不到验证码就登不进来」这个单点问题补掉。
• 为后续的风控与账号安全能力留下挂钩点：密码 + 设备 + 通知三条线索。

用户目标

• 想设密码的人能找到地方设置，并且明确知道「设了之后验证码登录依然可用」；
• 忘记密码的人能自己救回来（本期靠短信验证码）；
• 输错密码的人知道还能试几次、什么时候能再试、还有哪条路能走。

1.4 成功指标（上线首月，目标值需先取基线再锁定）

---

二、范围

2.1 本期做

• 登录页新增「密码登录」入口 + 密码登录页（含密码错误 / 次数超限锁定 / 该号未设置密码三种结果）
• 「我的 → 隐私和安全」新增「登录密码」行，含设置 / 修改 / 关闭
• 忘记密码：短信验证码 → 设置新密码 → 用新密码登录
• 「没收到验证码？」自助排查页（无客服口径）
• 系统通知沿用官方账号「U8 Chat」：新用户首次登录 / 登录验证码 / 新设备登录（密码登录也发）
• 密码规则校验、密码错误次数与锁定

2.2 本期不做（明确划出）

---

三、核心决策：做了密码登录，为什么不再单独做两步验证（2FA）★

这一章正面回答产品提出的问题：「有了密码登录，是不是就可以不做两步验证了？」
结论：可以不做的，本期也建议不做。 下面按「概念 → 能力 → 代价 → 兜底 → 触发条件」说清。

3.1 先把三个容易混的东西分开

关键区别：密码登录与验证码登录是两条平行的路（二选一），不是同一条路上的两道关卡。所以「做了密码登录」不等于「已经做了两步验证」—— 两者解决的不是同一个问题。但正因为密码提供了第二条独立的进门路径，2FA 的必要性反而下降（见 3.3、3.4）。

3.2 2FA 能防什么

2FA 的收益只有一条：当第一个因子泄露时，攻击者仍然需要第二个因子。

而 U8 的现实是：主登录方式就是验证码。攻击者要进门，通常得先控制手机号（补卡 / 换绑）或控制一台已登录设备 —— 这两件事 2FA 都拦不住。真正拦得住、且事后能止损的是「登录通知 + 远程注销」（见 3.4）。另外，验证码作为第二因子，本身并不比密码更"硬"：短信可以被劫持，而手机号还可能被补卡。

3.3 2FA 的代价（本期尤其不该做的理由）

3.4 U8 已有的兜底（覆盖面比 2FA 更广）

一句话：U8 的安全投入放在「登录之后」（可见、可止损），而不是「登录那一刻」（不可见、一旦忘记就锁死）。在只有手机号一个账号体系、且没有客服的阶段，这是更划算的一侧。

同时要点明：「二次验证」这个需求并不等于 2FA。产品希望的那种"关键操作再确认一次"的能力，已经通过上表最后一行被满足了，只是它不叫两步验证。

3.5 什么情况下应该回头做 2FA（触发条件，写下来备查）

出现以下任意一条，重新评估：

1. 客服 / 账号申诉通道上线（忘记密码能被人工救回）—— 这是最前置的条件；
2. 数据上出现「密码被撞库后成功登录」的真实案例；
3. 密码登录成为主要登录方式（占比 > 50%）；
4. 监管或合规要求。

如果将来做，建议形态是「可选开启」的 2FA：默认关闭，用户主动开启；开启时要求绑定手机号并生成一组恢复码（Recovery Code），并明确告知「忘记密码只能靠恢复码或人工核验」。不要做成默认强制。

---

四、名词定义

---

五、用户与场景

---

六、功能总览

                        ┌───────────────────────────────────────────────┐
                        │  登录页（A1）                                  │
                        │  手机号 + 验证码        ← 默认（原样保留）      │
                        │  「密码登录」            ← 本次新增             │
                        └───────┬──────────────────────┬────────────────┘
                                │                      │
                    验证码路（原样保留）          密码路（本次新增）
                                │                      │
              ┌─────────────────▼──────────┐  ┌────────▼────────────────────┐
              │ 验证码页：已开发完成        │  │ 密码登录页（A3）             │
              │ · 没有账号 → 自动注册+登录   │  │ · 密码错   → A4（还剩几次）  │
              │ · 有账号   → 直接登录        │  │ · 错太多   → A5（锁 15 分钟）│
              │                             │  │ · 没设过   → A6（回验证码）  │
              │ （不在本次演示范围）        │  │ · 忘记密码 → C1              │
              └─────────────────────────────┘  └─────────────────────────────┘
                                               └─────────────────────────────┘

   已登录侧（B）                          忘记密码（C）
   ┌───────────────────────────────┐     ┌────────────────────────────────────┐
   │ 我的 → 隐私和安全（B1）        │     │ 忘记密码（C1）                     │
   │ 「登录密码」= 未设置 / 已设置  │     │   → 短信验证码（C2）                │
   │  ├ 设置（B2 → B3）             │     │   → 设置新密码（C3）                │
   │  ├ 修改（B4 → B5）             │     │   → 重置成功（C4）                  │
   │  └ 关闭（B6）                  │     │   → 其它设备上的登录全部失效        │
   └───────────────────────────────┘     │ 收不到短信 → 自助排查（C5）        │
                                          └────────────────────────────────────┘

   共用兜底（D）：官方账号 U8 Chat 的新设备登录通知（D1）· 设备管理里远程注销 · 扫码登录

6.1 页面清单

---

七、需求详述

7.1 登录页与「首次登录即注册」#A1（P0）

入口：App 启动后未登录 → 直接落在登录页。这一页的默认方式不变，仍是验证码登录。

验证码登录 = 首次登录即注册（本次不变）

登录验证码页（输入 5 位验证码那一屏）已经开发完成，本演示与 UI 都不再重复画（2026-09-23 产品确认）；下面这段讲的是服务端判定，仍然成立。

用户输入手机号 → 点「继续」→ 发验证码
   → 输入验证码 → 服务端校验
       ├─ 手机号在库里不存在 → 创建账号 → 登录成功 → 该设备收到「新用户首次登录」欢迎消息
       └─ 手机号已存在       → 直接登录

⚠️ 不要为了"密码功能"在登录页加「注册」按钮或「密码登录 / 注册」两个 Tab —— 那会把一个无感的自动注册变成用户要做的选择题。

按设计稿还原（2026-09-23 拿到画板后）：登录页 1:1 照 Figma 画板「登录」（1092:66063）—— 标题「手机号登录」· 副标题「未注册的用户，验证后将自动注册账号并登录」· 国家行「🇨🇳 中国」· 号码行 +86 + 占位 000 0000 0000（带下拉尖角）· 灰色「继续」· 底部「○ 登录即代表同意用户协议和隐私政策」· 右上角「网络诊断」，逐字逐项照画板。按钮空输入时置灰（画板画的就是这个状态），输入 11 位号码后变紫。

★ 本次唯一的新增：同意条款行下方一行居中的紫色「密码登录」入口（走进 A3）。画板上既有元素的位置与文案一处未动。（入口放在哪儿是建议，最终由 UI 定。）

7.2 密码登录 #A3 #A4 #A5 #A6（P0）

入口：登录页底部「密码登录」（A1 → A3）。唯一入口，不在别处再放。

⚠️ 不支持「默认密码」：系统不提供任何默认密码，也不允许"没设置过密码就直接用密码登录"。密码只能由用户自己设置（B1 → B2）；没设过密码时，点「登录」一律走 A6（提示用验证码登录）。这是本功能的硬前提（2026-09-23 产品明确）。

点「登录」的结果分支

规则

• 不发验证码：密码登录与验证码通道无关，因此不受「验证码只发已登录设备」的限制 —— 这正是它作为备用入口的价值。
• 新设备上直接放行（已拍板）：不要求第二因素，风险由「新设备登录通知 + 设备管理远程注销」承担。
• 不做「记住密码 / 记住我」勾选框（2026-09-22 已拍板）：登录态默认记住（与验证码登录一致）；要退出走「我的 → 退出登录」。
• 不改动登录页的默认方式：默认永远是验证码登录。
• 密码字段不做长度预校验：位数/规则只在服务端判定，客户端只负责拦截"空密码"。

7.3 设置登录密码 #B1 #B2 #B3（P0）

入口路径：我的 → 隐私和安全 → 登录密码。入口页 1:1 照 Figma 画板「我的-隐私和安全」（802:128996）：卡片一 = 已拉黑的用户（2）/ 锁定码&Face ID（关闭）/ 登录密码（本次新增） / 资金密码（已设置）/ 密保问题（未设置）；卡片二 = 手机号（不允许任何人）；卡片三 = 注销账号（红字）。

★ 本次唯一的新增：在「锁定码&Face ID」与「资金密码」之间插入一行「登录密码」（绿色钥匙图标），值两态 未设置 / 已设置；其余每一行都是画板原样。（行放在哪儿是建议，最终由 UI 定。）

B2 设置页

B3 成功弹窗：紫圆 ✓ +「登录密码已设置」+「现在可以用手机号 + 密码登录 U8 Chat。忘记密码时可以通过短信验证码进行重置。」+「完成」→ 回 B1（该行值变「已设置」）。

• 设置密码不产生新登录，因此不发「新设备登录」通知。
• 设置成功后不发账号安全通知（2026-09-22 已拍板）：设置密码没有产生新登录，通知会变成噪音。

7.4 修改登录密码 #B4 #B5（P0）

B5 成功弹窗：紫圆 ✓ +「登录密码已更改」+「为保护账号安全，其它设备上的登录已全部退出。请用新密码重新登录。」+「去登录」→ A3（密码登录页）。

• 本机也被登出，所以唯一出口是把用户送回登录页，而不是回「隐私和安全」。

7.5 关闭登录密码 #B6（P1）

7.6 忘记密码 #C1 #C2 #C3 #C4 #C5（P0）

入口：密码登录页的「忘记密码？」（A3）。唯一入口 —— 登不进来的人进不去设置页。

A3 忘记密码？ → C1 发送验证码（号码只读）
   → C2 输入验证码短信（5 位 / 5 分钟）
       → 校验通过 → 签发一次性重置票据（10 分钟）
           → C3 设置新密码（双输入）
               → C4 重置成功（其它设备登录全部失效）→ 去登录（回 A3）
       → 收不到短信 → C5 自助排查 → 重新发送（回 C2）

规则

• 只走短信：忘记密码的用户可能没有任何活跃设备，因此这条流程不能把验证码发到官方账号会话（与登录、换绑的通道规则不同，这是有意为之）。
• 不泄露号码是否注册：该号码不存在时，同样提示「验证码已发送」。
• 重置票据：10 分钟有效、一次有效；过期或复用 → 「本次操作已超时，请重新验证手机号」。
• 重置后注销该账号其它所有设备（2026-09-22 已拍板）：重置密码通常意味着用户怀疑账号出了问题，保留其它会话等于把风险留着。（换绑手机号采用「不强制下线」，因为那是正常使用中的用户 —— 两处口径不同是有意的。）
• 被下线的设备不推送，下次打开 App 时提示「登录已失效，请重新登录」。
• 不做冷却规则（如"重置后 N 小时内不能再改"）：没有客服，误伤没法救。

7.7 系统通知与安全兜底 #D1（P0）

承载方式沿用「设备管理」6.9.1，不重新定义：官方账号「U8 Chat」，带认证标识、像用户一样出现在会话列表、可聊天，状态显示「客服」。

本次新增带来的变化

• 密码登录不发验证码：不产生 ②；登录成功时产生 ③。
• 「③ 新设备登录」的文案里，兜底出口只有「我的 → 设备」终止会话（不含「修改登录密码」，也不含「联系客服」—— 2026-09-23 拍板）。
• 三处验证码场景（登录 / 换绑 / 忘记密码）的短信文案统一，且都不出现「联系客服」。

---

八、规则与边界

8.1 密码规则

8.2 密码错误与锁定

与换绑的差异：换绑是「错误 5 次/小时 → 锁 24 小时」。密码登录是高频入口，误伤成本更高，所以起跳更短（15 分钟）；24 小时档留给"反复触发"。

8.3 验证码参数（全站统一，与「修改手机号」一致）

2026-09-22 已拍板：验证码位数全站统一 5 位（登录 / 换绑 / 忘记密码共用同一套验证码服务，见 决策 20）。任何一处要改位数，三处必须同时改。

8.4 状态对照表（一屏看全）

8.5 多端并发与中断

同一账号允许在多端同时保持登录（2026-09-22 已拍板，沿用现状）；密码变更不强制登出其它端（见 7.4）。

8.6 与扫码登录、设备管理的关系

8.7 号码与账号边界

---

九、跨端行为

Web / Desktop 为什么不做

1. Web / Desktop 的登录已经被扫码登录覆盖（设备管理 6.8：电脑端出二维码 → 手机端确认授权），用户不会因为"Web 上没有密码登录"而登不进来；
2. Web 上的密码输入与「扫码 + 手机端确认」是两套安全模型，混在一起会出现「电脑上输密码就直接进，不需要手机确认」的绕过路径 —— 这会削弱设备管理刚建立的那道确认；
3. Web 端的登录页是另一套实现（不在本次的原型与设计范围内），不做更干净。

跨端一致性要求（给研发）：验证码参数、密码错误计数与锁定、错误码语义必须由服务端统一，各端只负责展示。任何一端自行放宽校验，都会让另外两端的锁定失效。

---

十、文案（可直接落地）

A · 登录与注册

B · 设置与修改密码

C · 忘记密码

通用（沿用客户端现有文案，不新造）

---

十一、接口与埋点

11.1 接口

两条硬约束（给研发）

• 重置-提交接口的号码必须从 reset_token 取，客户端不得传号码（否则可越权改任意账号的密码）；
• 「设置密码 / 修改密码 / 关闭密码」接口必须校验当前密码或登录态 + 二次校验，不得只认登录态（否则拿到已解锁手机即可改密码）。

11.2 埋点

---

十二、验收标准

1. 未登录打开 App 落在登录页，默认仍是验证码登录；底部有「密码登录」入口。
2. 新用户手机号首次登录即注册：号码不存在时，验证码验证通过后直接登录成功，页面上不出现「注册」字样，且该设备收到官方账号的「新用户首次登录」消息。
3. 已设置过密码的账号：手机号 + 正确密码 → 直接登录成功；其它在线端收到「新设备登录」通知。
4. 密码错误时给 iOS 弹窗，文案含剩余次数；点「好」后手机号保留、密码清空。
5. 连续错 5 次锁定 15 分钟；锁定期内即使密码正确也不放行；验证码登录始终可用。
6. 从未设置过密码的账号走密码登录 → 弹窗「这个账号还没有设置登录密码，请用验证码登录」，点「好」回登录页并带入手机号。
7. 手机号不存在的提示与 #6 完全一致（不泄露号码是否注册）。
8. 「我的 → 隐私和安全 → 登录密码」行的值随之正确变化：未设置 / 已设置。
9. 设置密码：双输入一致且符合规则才能成功；成功后弹窗明确「忘记密码时可以通过短信验证码进行重置」，返回后行值变「已设置」。
10. 修改密码：必须输对当前密码；当前密码错误走独立文案，不计入登录错误次数。改成功后所有会话（含本机）退出，弹窗「去登录」把用户送回登录页；另：设置 / 修改 / 重置三处的密码输入框默认隐藏（掩码），右侧眼睛图标可切明文。
11. 关闭密码：必须校验当前密码；确认弹窗为「取消 ｜ 关闭」两按钮；关闭后行值回到「未设置」，且其它设备不被登出。
12. 忘记密码：号码只读；走短信验证码（即使该账号有活跃设备）；校验通过后才能设置新密码。
13. 重置成功：该账号其它所有设备上的登录失效；被下线的设备下次打开提示「登录已失效，请重新登录」。
14. 重置票据：10 分钟有效、一次有效；过期或复用给「本次操作已超时，请重新验证手机号」。
15. 「没收到验证码？」页存在，三条自查 + 停用/丢失的说明齐全，全站文案不出现「联系客服」。
16. 密码相关的所有弹窗、按钮在浅色背景下白字可读（对比度 ≥ 3.4）。
17. 演示页 index.html 的 18 屏全部可点、无死链；筛选「核心路径 / 规则与状态」计数正确。

---

十三、决策与待确认

13.1 已决策（产品已拍板，开发可直接依此执行）

13.2 待确认（不阻塞开发）

（2026-09-23 补充） 登录页的「国家/地区」可以切换（产品已确认，是已开发好的功能）—— 本次不画；早期本 PRD 曾擅自写成「固定 +86、不可点」，已撤。
版式类问题不再列在这里 —— 入口摆哪儿、按钮放哪，本演示给建议、最终以 UI 设计为准（见决策 23）。下表只剩流程与内容类的 2 条。

---

十四、与其它交付物的关系 / 相对现状改了什么

14.1 与其它交付物的边界

14.2 相对现状改了什么

1. 登录页多一个入口：「密码登录」（默认仍是验证码登录）。
2. 新增密码登录页及其三种结果（密码错 / 锁定 / 未设过密码）。
3. 「我的 → 隐私和安全」多一行「登录密码」（未设置 / 已设置），含设置、修改、关闭三条路径。
4. 新增忘记密码流程（短信验证码 → 设置新密码 → 重置后其它设备失效）。
5. 新增自助排查页「没收到验证码？」（因为本期没有客服）。
6. 安全兜底补一句：新设备登录通知 / 换绑后的安全提示里，出口从"改密码"变为可落地的「我的 → 隐私和安全 → 登录密码」。
7. 明确不做：两步验证（2FA）、邮箱找回、密码提示、账号申诉（第三章 + 2.2）。

14.3 相对设计稿改了什么

14.4 设计图里有哪些相关画板（2026-09-23）

产品给的 UI 设计稿是 Figma 文件 「U8 Chat」umRiEY84pJQmfomeNkbjOf · PAGE「iOS端」1:218 —— 与「修改手机号」用的「U8 Chat 2.0」6dsI4eKdAoZr4RP0uILIBq 不是同一个文件。逐屏核对结果：

结论：这份设计图里没有「登录密码」相关的任何画板。但如信息表所说，设计图不全（老 UI 同事做的功能不在里面），所以不能据此断定"UI 没做过这套流程" —— 已开发完成的部分由产品确认（例：登录验证码页就是产品确认已开发完、本次不画的）。本演示与 PRD 的价值是：给 UI 一份「要画哪些页面、从哪儿进、每页什么规则」的清单。已有设计的两个页面我们按它 1:1 还原并在其上各加一处入口；其余 18 屏是建议稿，UI 出图后以 UI 为准（决策 23）。

顺带核到的其它画布内容（不在本次范围，仅供参考）：我的-更改手机号 11 屏（＝「修改手机号」交付物）、资金密码 系列 9 屏、web端扫码登录后-移动端接收到「登录确认」、被注销设备端-退出登录、以及首页 / 资产 / 群聊等大量既有画板。

---

十五、附录：演示页索引（index.html，18 屏）

主流程演示顺序：A1（点「继续」后是已开发完成的验证码页，不进演示）· A1 → A3 → A4 / A5 / A6（密码登录的三种结果）· A3 → C1 → C2 → C3 → C4（忘记密码）· B1 → B2 → B3 / B4 → B5 / B6（设置与修改）。