#恢复码与身份找回

现状：跨设备找回身份，优先用 用户名 + 密码。恢复码是早期「纯 Cookie 身份」时代的自助方案，现仍可用，但属于兼容能力，新用户不必依赖它。

#为什么会有恢复码

mdocs 初期刻意不做传统登录系统：不想要注册邮箱、账号密码那一套，希望打开就能写。

底层做法是：浏览器里通过 HttpOnly Cookie 下发一串随机高熵令牌，服务端只存其哈希，用这份 Cookie 标识「你是谁」。没有单独的账号表登录流程。

代价也很直接——Cookie / 本机身份数据一旦丢了（清站点数据、换浏览器、换设备），浏览器再也带不上原来的令牌，系统就认不出你还是以前那个人，文档所有权也接不上。

恢复码就是为这个问题准备的：一份由用户自己保存的一次性凭证，在 Cookie 丢失后，仍能凭码换回同一访客身份和新的 Cookie。

#后来发生了什么

后续迭代引入了 登录密码（访客名 + 密码，可多设备会话）：

• 跨浏览器 / 跨设备：用密码登录即可，不必再找恢复码
• 注册时可设密码；设置页可管理「登录密码」
• 登录弹窗默认是「用户名 + 密码」；恢复码仍作为次要入口保留

因此恢复码的核心场景被密码覆盖，功能逐渐被边缘化，保留是为了兼容早期只靠 Cookie、已发过恢复码的用户。

#机制摘要（仍可用时）

格式形如：

ABCD-EFGH-IJKL-MNOP

• 注册成功时可能弹出展示（只此一次）；也可在设置页「通用 → 恢复码」重新生成（旧码立即失效）
• 服务端只存 SHA-256 哈希，不能再把明文码「查出来」给你看
• 在登录弹窗切到「恢复码」，输入后换发新的身份 Cookie；验证成功后该码作废（一次性）

#怎么用（兼容流程）

#生成 / 再生成

1. 打开 设置 → 通用 → 恢复码
2. 点击生成，立刻复制保存
3. 再生成会使旧码失效

#用恢复码找回

1. 无有效 Cookie 时打开站点，进入注册 / 登录弹窗
2. 切到登录 → 恢复码
3. 输入保存的码 → 找回身份

#常见问题

#还需要保存恢复码吗？

若已设置登录密码，日常以密码为准即可。恢复码可选：仅当你希望多一条不依赖密码的兜底时再保存。

#恢复码丢了怎么办？

• 仍能进当前浏览器会话：去设置页改/设密码，或再生成恢复码
• 已进不去：有密码就用密码登录；都没有则联系管理员做 visitor migrate

#恢复码和 Cookie 令牌有什么区别？

#和「无账户」设计还一致吗？

早期「无账户」指的是不做邮箱注册那套，用 Cookie 访客身份。现在的「访客名 + 可选密码」仍是轻量访客模型，不是完整的企业账号体系；密码解决的是 同一访客跨端续上身份，并不否定当初降低门槛的目标。身份模型细节见 无账户身份识别。