外观
Nexo — 2026-08-30 迭代需求文档
范围来源：2026-08-23 验收会记录的「记录」「bug」「候补」「技术方案」四部分。 验收标准见同目录 TC 文档，本文档只定义"做什么"。
1. 功能需求
1.1 设备与登录态
FR-1 设备识别
- 同一台设备生成的 id 必须一样：重启应用、重启系统、退出后重新登录，标识不变；不同设备之间不冲突
- 粒度为端级：一台机器上的桌面端、Chrome、Safari 各算一台设备，「登录设备」里是三条。三者凭证存储强度与能力不同，合并成一条就无法单独吊销
- 桌面端：重装应用后仍是原来那一条，不新增
- 网页端：同一浏览器多次登录算同一台设备——退出再登、关掉重开、令牌过期后重登，都复用同一条设备记录，而不是每次新建一条
- 设备记录按账号归属：不同账号在同一浏览器登录，各自是独立的一条，互相看不见
- 网页端的边界：清空站点数据即视为新设备。浏览器里没有任何合法手段能读到机器标识，这是 Web 的边界而非缺陷，「登录设备」列表如实呈现即可
- 实现方式（标识取自哪里、如何持久化、如何防篡改）见第 3 节技术方案
FR-2 登录设备信息增加【地址】
- 「登录设备」列表新增地址列，展示最近一次活跃的来源 IP 与归属地（城市级即可）
- 查询失败显示"未知"，不阻塞列表渲染
FR-3 App 内置登录，不跳浏览器
- 桌面端登录在应用内完成，不再打开系统浏览器
- 登录页由应用内 WebView 加载认证中心托管的页面：表单渲染与提交都在认证中心自己的页面里，应用不自绘登录表单、不读取表单内容
- 仍走认证中心的正式流程（授权码 + PKCE），不新开登录接口
- 该改动使上期「密码不经过应用本体」这条安全属性失效，上期 TC 的 A4 作废重写
密码是否经过应用本体，不作为设计约束。 Nexo 是第一方自有应用、5 人内部、不开放注册，为这一条牺牲交互不划算。真正的防护改放在密码本身——端侧先做单向加密再传输（见 FR-13），服务端拿到的就不是明文。
FR-4 网页端与桌面端登录状态同步
- 网页登录页检测到本机 APP 已登录时，直接走客户端认证，不用输入账号密码
- 两端登录状态保持独立：网页端与桌面端各自一台设备、各自一条会话记录，踢掉一个不影响另一个
- 同步是单向的：网页端读桌面端，桌面端不读网页端
- 桌面端未运行或未登录时，网页端安静回退到常规密码登录，不弹错误
- 本地通道安全边界（准入条件，非优化项）：
- Origin 白名单 + 严格 CORS。任何网站的 JS 都能访问
127.0.0.1；若不校验 Origin 或设了Access-Control-Allow-Origin: *，用户打开恶意站点的那一刻登录态即被静默取走 - 每次都要确认：每次索取登录态都在桌面端弹窗，弹窗显示请求方是谁；不记住 Origin，也不提供"下次不再询问"。免掉的是输账号密码，不是免掉用户的知情与许可
- 本机恶意程序直连该端口不在防护范围内（该场景下系统凭证库同样保不住）
- Origin 白名单 + 严格 CORS。任何网站的 JS 都能访问
FR-13 密码端侧单向加密
- 登录时客户端先做单向加密，传输的是加密结果；明文密码不出客户端
- 服务端收到后再做一次单向加密才落盘，两次使用不同的算法（或相同算法配不同密钥）
- 由此服务端永远接触不到明文：日志误记、内存转储、内部人员窥探都拿不到；用户在别处复用同一密码时，也不会被我们连带
- 但这不替代传输层安全：端侧加密的输出就是事实上的凭证，截获它即可登录、无需还原原始密码。HTTPS 一条都不能松
- 也不会让数据库泄露的后果变轻：原本存的就是不可逆哈希，泄露后同样无法直接登录。这次改造买到的是"服务端看不见明文"，不是别的
- 盐的取法不得泄露账号是否存在——不许用"登录前向服务端索取该用户的盐"这种做法，它直接撞上期 TC 的 A8（错误密码与不存在的账号，响应必须不可区分）
- 现有账号密码全部需要重置一次：存量哈希按明文算，改造后失效，而服务端没有明文、无法自动迁移。5 个种子账号，重置成本可忽略
1.2 连接与会话
FR-5 心跳包与连接回收
- 补充心跳包用于验证长连接是否存活
- 判定失活后，只释放服务端的连接资源（socket、连接槽位、在线态路由表项）
- 失活不等于退出登录：不清认证会话、不吊销令牌、不删设备记录。「登录设备」里该条记录保留，只把在线状态改为离线
- 客户端重连时用现有凭证直接恢复长连接，不要求重新登录
- 判死阈值（心跳间隔、连续丢失次数、判死超时）可配置，不写死在代码里，配置项同步进部署文档
- 客户端主动断开与被动失活，服务端行为一致：都释放连接资源、都不留僵尸连接，也都不动登录态
- 网络抖动导致的短暂断开，重连后不得要求重新登录
这里明确掉的是"连接断了 = 人走了"这个等号。长连接掉线的常见原因是网络切换、设备休眠、隧道超时，与用户是否还想保持登录无关；按退出处理会让用户合上笔记本再打开就得重新登录一遍。真正该动登录态的只有三条路径：用户主动退出、被其他端踢下线、令牌到期（见 BUG-6）。心跳判死不在其中。
1.3 消息
FR-6 消息时间精确到秒
- 气泡时间展示到
HH:MM:SS，跨天显示日期 - 会话列表预览与聊天详情的时间口径一致
FR-7 消息撤回
- 发送方可撤回自己发出的消息。第一版不设撤回时限——多久以前发的都能撤，服务端不做时间校验
- 撤回后双方界面统一替换为「XX 撤回了一条消息」
- 多端同步：发送方其他设备、接收方所有设备都要更新；离线设备上线后拉到的也是撤回后的状态
- 已撤回消息的正文不能再通过任何接口拉到，不能只在前端隐藏
- 但正文本身要留着：将来的消息复核与合规检查，最需要看的恰恰是被撤回的内容，删掉等于自毁证据。要求是"业务接口拿不到"，不是"数据不存在"——技术方案须给出结构性隔离，而非靠每个接口记得过滤
- 时限是后续可能补的策略，本期技术方案需把它留成服务端可配的校验点，将来开启不改协议、不动客户端
FR-8 消息本地存储与多设备同步
- 消息在客户端本地存储，重启 / 离线时可查看历史
- 卸载重装不丢：卸载应用再重装，本地消息仍在。只有两种情况允许丢失——用户在卸载时勾选「同时删除本地消息」（默认不勾），或在应用内主动清空
- macOS 没有标准卸载器（拖进废纸篓即卸载），数据天然保留；因此应用内必须提供「清空本地消息」入口，那是唯一的清理途径
- Windows 卸载器需显式保留数据目录，并在卸载界面提供该勾选项
- 网页端无"卸载"概念，清空站点数据即丢失，与 FR-1 的设备标识同命
- 多设备登录时，用户可按 设备｜时间 自由选择要同步的消息。选的是数据来源——在 B 设备上选「从 A 设备同步 X 月 X 日至今」，而不是展示层过滤
- 批量同步只走 P2P，不允许经服务端中转
- 历史消息是 GB 量级，经服务器中转会把进出流量直接刷爆
- 本条只约束批量历史同步。新消息推送、增量拉取、会话内向上翻页属常规业务请求，照常走服务端，不受此限
- 允许跨网段：接入公共 STUN 以发现公网地址
- 不用 TURN——它中继全部流量，与本约束直接冲突
- 传输须压缩后加密
- 建连不通就不支持同步：明确提示用户当前网络无法建立设备间连接，不降级、不走服务端
- 离线设备不支持（对方不在线就同步不了，不做中转与补偿）
- 退出登录时本地消息按账号隔离，不能被下一个登录者读到
- 归档与导出能力：本期不新增，但设计不得堵死
- 服务端现有的消息存储照旧不动——常规历史分页依赖它，本期不做任何削减
- 本期不新增的是归档、导出与合规检查这层能力：长期留存策略、导出接口、复核视图，一个都不做
- 它们是已确认的后续方向——要做消息复核与合规检查，也可能需要配合三方做消息导出
- 因此本期的消息模型（消息 id、会话 id、发送方设备、时间戳、撤回态）须是服务端侧可复原的完整形态，不得设计成"只有客户端才拼得出一条完整消息"。将来开启持久化不应要求客户端改协议或回填历史
- 本期不要求任何存储实现、不要求出表结构（登记见第 5 节）
FR-9 未读消息系统提醒
- PC 桌面端：程序进入后台 / 最小化 / 失焦后收到新消息，发系统消息通知；点击通知直达对应会话
- 网页端：使用浏览器原生通知方法，首次使用时请求授权；用户拒绝后降级为标题提示，不反复弹窗
- 应用在前台且正停留在该会话时不发通知
- 未读只被消费一次：未读是账号级的，不是设备级的
- 一条消息的未读被任意一台设备读掉之后即视为已消费，其余各端的未读计数、红点、角标同步清零
- 服务端不得把同一条未读当成"每台设备各存一份"、让多端各消费一遍。同一账号下多设备登录，消费的是同一份数据
- 离线设备上线后只拉到当前真实未读，不补发已被别的设备读掉的那些，也不把它们重新计进未读
- 通知与未读态区别对待：多台设备同时在后台时通知可以都弹（提醒是尽力送达，用户不一定守在哪台机器前）。一端读了之后，其余端不再弹新通知；已经弹出去的不撤回——撤回要维护通知句柄且各平台能力不一致，收益只是消掉一条用户已经看过的提示，不值得为它引入额外逻辑
为移动端推送留口子（本期只留设计，不做实现）
移动端 App 切到后台会被系统冻结，长连接与本地定时器都会被切断——桌面端"应用自己判断该不该弹通知"这套做法在移动端根本跑不起来，通知必须由服务端经 APNs / FCM 投递。如果本期把通知逻辑写死在客户端，将来接移动端要整条重做。
因此本期的实现约束：
- 通知决策与投递通道解耦：服务端负责判断"该不该通知哪台设备"，通道只负责"怎么送达"。本期通道只实现"在线经长连接下推、由客户端唤起本地通知"这一条，但新增通道不得要求改动决策逻辑
- 设备记录预留推送凭证字段（通道类型 + push token），本期不写入、不使用
- 本期不接入 APNs / FCM，不做移动端（见第 6 节）。这里只要求接口形状留得住，不要求任何移动端代码
1.4 桌面壳
FR-10 应用外框自绘
- 不使用系统原生标题栏，自己实现：标题栏、最小化 / 最大化 / 关闭、拖拽移动、双击最大化、边缘 resize
- macOS 与 Windows 两个平台行为都要正常
FR-11 应用图标 Logo
- 桌面包（macOS
.icns/ Windows.ico）、Web 端 favicon、登录页与关于页共用同一套视觉资产 - 设计资产由谁产出、什么时候给需在评审时确认；没有资产则本项交付不了
1.5 工程
FR-12 部署文档归档
- 每个项目的部署文档（现各仓库的
docs/deploy.md）统一放到 docs 项目下集中维护 - 不要出现在网页上 —— 不渲染进文档站，部署文档含域名、环境变量结构、反代配置
- 迁移后各仓库留下指向新位置的索引
2. 缺陷修复
会上记录的 10 条，逐条给出正确行为。每条都要有对应 TC 用例，"看起来好了"不算修复。
2.1 认证与登录态
| # | 缺陷 | 正确行为 |
|---|---|---|
| BUG-1 | 授权登录成功之后自动关闭 | 授权完成后正常回到应用主界面，窗口不自行关闭 |
| BUG-2 | 桌面端退出登录后无法操作页面 —— 退出登录没有清掉认证信息 | 退出时清干净该端的认证信息与界面状态，不留中间态，可继续操作并回到登录页 |
| BUG-3 | 旧 token 重放直接将两条认证清除 | 只吊销涉事的那一个端，同账号其他端不受任何影响 |
| BUG-4 | 越权请求的时候把当前登录用户状态清除 | 403 与 401 必须区分：401（凭证失效）才清凭证回登录页；403 只提示无权访问，登录态保持不变 |
| BUG-5 | 强制下线没有页面提醒 | 被踢端明确提示「你的账号已在其他设备上退出登录」 |
| BUG-6 | 是否会有一个自动退出登录的时间 | 本期必须给出确定答案而非"看情况"：定义 ① 刷新令牌绝对有效期 ② 连续空闲多久要求重新登录 ③ 到期时给用户什么提示。数值见第 4 节 |
2.2 IM 与界面
| # | 缺陷 | 正确行为 |
|---|---|---|
| BUG-7 | 聊天框不同用户数据未隔离，切换通讯录再切回，输入框内容被清除 | 草稿按会话隔离并保留：切走切回内容还在，不同联系人的草稿互不串扰 |
| BUG-8 | 退出登录不会清除未读消息 | 退出时清空内存中的会话、未读、草稿状态；本地消息库按账号隔离保留（见 FR-8），换账号登录用的是另一个库，看不到上一个账号的任何数据 |
| BUG-9 | 消息多了会出现滚动条，导致布局偏移 | 直接隐藏滚动条，消息增减不引起布局位移 |
| BUG-10 | 桌面端空白区左滑右滑会出现白边 | 横向滚动溢出消除，两个平台都要修 |
3. 需要先出技术方案的项
以下六项在开发前必须有技术方案，与本 PRD 一并评审：
- 心跳包 —— 阈值配置项、判死后的连接资源释放链路（须说明为什么不会连带动到登录态）、误判恢复与重连
- 设备识别方式 —— 两端各自的稳定标识取自哪里、如何持久化、如何防篡改；「一台设备 = 一条记录」在数据模型上怎么落，与"每次登录一条记录"的现状怎么迁移。另需一并给出 FR-9 通知通道抽象的接口形状、以及未读的账号级消费与跨端已读同步怎么落（不单列方案）
- 网页端、桌面端状态同步 —— 时序图必需，含本地通道的 Origin 校验、每次确认的交互与文案、端口占用时的回退
- 消息撤回 —— 存储形态、多端同步、离线设备补偿、时限校验点预留在哪
- 消息本地存储与同步 —— 两端本地库形态（须满足卸载重装不丢）、按设备/时间的同步协议、WebRTC 建连与失败处理、压缩与加密方案；消息模型须说明将来加归档与导出能力时怎么不改客户端协议
- 密码端侧加密（FR-13） —— 两段算法选型与参数、盐的确定性派生方式（须避开 A8 的账号枚举）、存量账号的重置方案
4. 待评审收口
| # | 待定 | 倾向 | 不定会怎样 |
|---|---|---|---|
| 1 | 心跳判死阈值（间隔 / 丢失次数 / 超时） | 技术方案给建议值，评审拍板 | FR-5 写不出判定阈值 |
| 2 | 刷新令牌绝对有效期 + 空闲超时 | 同上 | BUG-6 无法验收 |
| 3 | Logo / 图标资产由谁产出、何时给 | —— | FR-11 交付不了 |
| 4 | FR-3 内置登录方向反转是否确认 | 会上已定，但推翻了上期已交付方案，需显式点头 | 返工风险 |
| 5 | FR-13 的端侧加密迭代次数 | 技术方案给建议值，需在最慢设备实测 | 登录按钮会卡顿 |
| 6 | FR-13 是否加服务端密钥（pepper） | 倾向本期不做——能防库泄露后离线爆破，但轮换即全员改密 | —— |
| 7 | 全员密码重置的时间点与通知方式 | 随发布一起 | 漏了会表现为"所有人都登不进去" |
原第 3 项「消息撤回时限」已收口：第一版不设时限，见 FR-7，不再作为待定项。
5. 候补（登记，本期不做）
- 加密通讯
- agent —— 云端调度、本地唤起、沙箱
- 服务端消息持久化与导出 —— 消息在服务端长期留存，用于消息复核与合规检查，并支持配合三方导出。后续确定要做，本期只按 FR-8 的约束保证消息模型不挡路，不写任何存储实现
加密通讯与服务端消息持久化这两项互相打架，谁先落地谁定调：端到端加密后服务端拿到的是密文，复核、合规检查、导出都做不了。两个都要，就得先决定密钥怎么处理（托管、双写明文、还是只在客户端侧导出）。本期不解，但排期时不要让这两项各走各的。
6. 明确不做（Out of Scope）
- 移动端 App 本体，以及 APNs / FCM 推送接入 —— 本期只按 FR-9 预留通知通道接口与推送凭证字段，不写任何移动端代码
- TURN 中继、对称 NAT 穿透、离线设备的同步中转与补偿（见 FR-8 的边界）
- 应用注册表（多子应用列表、侧边栏切换、多 iframe 生命周期管理）
- 壳与子应用之间的双向 RPC 契约
- 前后端 SDK 的正式发包与版本管理
- 桌面包代码签名与公证、应用内自动更新、Linux 包
- 验收用例自动化（Playwright E2E）
- 前端统一日志接入与日志上报
- OIDC 完整合规、第三方 IdP、开放注册、扫码登录
7. 非功能需求
- 桌面端设备标识：连续 10 次重启 + 一次重装应用后保持不变
- 网页端设备标识：同一浏览器内连续登录 / 退出 10 次，「登录设备」中始终只有一条对应记录；清空站点数据后新增一条属预期
- 连接失活到服务端连接资源被释放、该端在线状态转为离线：≤ 心跳判死阈值 + 5s；登录态与设备记录不受影响
- 失活后重连：客户端凭现有凭证恢复长连接，全程不出现登录页
- 强制下线生效 ≤ 5s（沿用上期指标，本期作回归）
- 撤回操作到两端界面更新 ≤ 2s（在线设备）
- 未读跨端消费：任一端读掉后，其余在线端未读计数归零 ≤ 2s；离线端上线后拉到的未读不含已被消费的
- 消息单向端到端延迟 ≤ 1s（沿用上期指标）
- 本地落库的消息按账号隔离，不能被下一个登录者读到
- 桌面端本地消息：卸载应用后重装，历史仍可读取（卸载时未勾选删除数据的前提下）
- 明文密码不出客户端：服务端、日志、数据库、任何中间环节都不得出现明文（FR-13）
- 规模按 5 人设计，单实例部署
8. 验收标准
见同目录 TC 文档。上期验收计划 45 分钟、实际 100 分钟，本期硬约束：会上用例 ≤ 10 条、单条判定 ≤ 3 分钟，其余离线并在 08-29 前跑完附证据（截图 / 日志 / 录屏）。TC 评审时会上用例超标，先砍用例。
9. 风险与降级
| 风险 | 降级预案 |
|---|---|
| 设备标识的系统级因子在某平台取不到或不稳 | 该平台降级为"应用数据目录内持久化标识"，稳定性要求降为"不主动清数据则不变"，并记录该平台的能力差异 |
| 心跳误判（网络抖动被当成失活） | 只丢连接、不丢登录态，客户端自动重连即恢复。这是 FR-5 改为"只释放连接资源"的直接收益——误判的代价是重连一次，不是重登一次 |
| P2P 建连失败 | 没有降级路径（服务端中转被流量约束排除）。会议室网络多半不通，验收前须实测，不通则改用手机热点组网，并如实说明真实网络下的可用性边界 |
| Windows 卸载器把数据目录一起删掉 | 「卸载重装不丢」是硬要求，删了即不通过；打包配置显式保留，发版前在干净环境实测装→用→卸→重装 |
| FR-3 改造引入认证回归 | 内置登录页复用认证中心既有流程、不新开接口；上期 A / C 两组用例全量回归 |
| 本地通道被做成"先能用再加安全" | Origin 白名单与 CORS 是 FR-4 的准入条件，未实现则该 FR 直接判不通过 |
| Logo 资产不到位 | FR-10 与 FR-11 拆开：窗口自绘照做，图标顺延，不捆绑 |
| 范围过载（13 个 FR + 10 条缺陷 + 6 份技术方案） | 挪出顺序：FR-11 → FR-6 → FR-9 → FR-8 的 P2P 部分。缺陷修复与 FR-1 / FR-5 / FR-13 不可砍——FR-13 牵动全员重置密码，中途放弃比做完更麻烦 |
10. 约束与说明
- 本文档只定义"做什么"；实现细节由第 3 节的技术方案确定
- 迭代目录以验收会日期命名（
YYYY-MM-DD） - 本文档需经研发评审后方可拆解为 issue，issue 统一挂 GitHub org project 供认领
- 节奏：08-24 定稿 → 08-25 上午 PRD + 技术方案评审并拆 issue → 08-25 至 08-29 开发 → 08-29 下午预跑 TC → 08-30 会上验收 45 分钟 + 15 分钟定下期
11. 名词解释
本章只解释本期新出现的术语，且只写它在本系统里的含义与作用，不做通用词典式定义。
上期已定义的术语（认证中心、资源服务、client、授权码模式、PKCE、访问令牌、刷新令牌、JWT、sid、吊销、吊销集合、复用检测、系统凭证库、webhook、壳、子应用、postMessage、Tauri、本地回环回调等）见 2026-08-23 技术方案第 13 章，本文沿用。
11.1 设备与标识
| 术语 | 含义 |
|---|---|
| 端级 | 设备的计数粒度。同一台机器上的桌面端、Chrome、Safari 各算一台设备——三者凭证存储强度与可用能力不同，合并成一条就无法单独吊销 |
| 设备标识 | 客户端持有并在每次登录时出示的稳定字符串，服务端据它判断"是不是同一台设备"。桌面端存系统凭证库、网页端存 localStorage，两端都是首次生成后不再变的随机值 |
| 站点数据 | 浏览器为某站点保存的本地内容（localStorage、cookie、IndexedDB 等），用户可在浏览器设置里一键清除。清掉即意味着网页端的设备标识丢失，下次登录算新设备 |
11.2 本地通道与浏览器安全
| 术语 | 含义 |
|---|---|
| 本地通道 | 桌面端在本机开放、供同机网页端索取登录态的接口，是 FR-4 的载体 |
| Origin | 协议 + 域名 + 端口三元组。浏览器在跨源请求中自动带上且不允许页面伪造，因此它是判断"请求来自哪个站点"的可信依据 |
| CORS | 浏览器的跨源资源共享机制。服务端用响应头声明允许哪些 Origin 读取响应，未声明则浏览器拦下响应体 |
Access-Control-Allow-Origin: * | 允许任意站点读取响应的通配写法。本地通道上禁止使用——等于把登录态对全网页面开放 |
| WebView | 嵌在原生应用里的浏览器控件。FR-3 用它加载认证中心托管的登录页；与系统浏览器的区别是它由应用进程控制 |
11.3 连接、会话与接口语义
| 术语 | 含义 |
|---|---|
| 长连接 | 客户端与服务端之间保持不断开的连接（本系统为 WebSocket），服务端可主动下推消息 |
| 心跳包 | 在长连接上定期收发的空报文，用于确认对端还活着。TCP 不会及时暴露"对端已消失"，所以需要应用层探测 |
| 判死阈值 | 连续多久收不到心跳就认定连接已失效。含心跳间隔、允许连续丢失次数、判死超时三个可配项 |
| 僵尸连接 | 连接实际已断、但服务端仍占着 socket 与在线态的连接。表现为「登录设备」里有一条永远显示在线、踢不掉也不会转离线的设备。FR-5 要回收的就是它 |
| 连接资源 vs 登录态 | 两样必须分开的东西。连接资源 = socket、连接槽位、在线态路由表项，掉线就该释放；登录态 = 认证会话、令牌、设备记录，只有主动退出 / 被踢 / 令牌到期才该动。FR-5 明确心跳判死只碰前者 |
| 401 / 403 | 两种不同的拒绝。401 = 你没有有效凭证（该重新登录）；403 = 凭证有效但你无权访问这个资源（不该动登录态）。BUG-4 正是把后者当成了前者 |
11.4 消息传输
| 术语 | 含义 |
|---|---|
| 本地落库 | 消息写入客户端本地数据库，使重启与离线时仍能查看历史 |
| 数据来源（对比展示过滤） | FR-8 中用户选的是"从哪台设备把消息取过来"，不是"在已有数据里筛出哪台设备发的"。前者会产生实际的设备间传输，后者只是前端过滤 |
| WebRTC | 在两个客户端之间建立点对点连接的标准。本期用它在设备之间直接传历史消息 |
| P2P | 数据在两台设备之间直接传输，不经服务端中转 |
| NAT 穿透 | 两台设备各自处在路由器后面、都没有公网地址时，设法建立直连的过程 |
| STUN | 帮设备发现自己公网地址的服务，只做地址发现、不经手数据。本期接入公共 STUN 以支持跨网段同步 |
| TURN | 穿不透时代为中继全部流量的服务。本期明确排除——它会让同步数据全部过服务器，与「同步不走服务端」的流量约束直接冲突 |
| 对称 NAT | 一类严格的 NAT，STUN 拿到的地址对其他对端无效，只有 TURN 能救。因此在对称 NAT 下同步不可用 |
| 同网段 | 两台设备连在同一局域网下，是 P2P 最容易建连的场景。本期不限于同网段——接入公共 STUN 后跨网段也可建连，只是成功率更低 |
| 服务端持久化 | 消息在服务端长期留存，区别于"投递完即弃"。本期不做，但它是消息复核、合规检查与三方导出的前提，故 FR-8 要求本期的消息模型不排斥它 |
11.5 通知与推送
| 术语 | 含义 |
|---|---|
| 通知决策 / 投递通道 | 前者判断"该不该给某台设备发通知"，后者负责"通过什么方式送达"。FR-9 要求两者解耦，否则将来接移动端要整条重做 |
| APNs / FCM | Apple 与 Google 的推送服务。移动端 App 被系统冻结后，只有经它们才能把通知送达 |
| push token | 推送服务分配给某台设备的地址，服务端凭它指定"推给哪台设备"。本期只预留字段，不写入不使用 |
| 未读消费 | 把一条未读读掉这个动作。本系统里未读是账号级的，一条未读只能被消费一次——A 端读了 B 端就没有了，而不是每台设备各消费一遍 |
11.6 界面与资源
| 术语 | 含义 |
|---|---|
| 原生标题栏 | 操作系统绘制的窗口顶栏，含关闭 / 最小化 / 最大化按钮。FR-10 要求改为应用自绘 |
.icns / .ico | macOS 与 Windows 各自的应用图标格式 |
| favicon | 浏览器标签页与书签上显示的站点小图标 |
| 归属地 | 由来源 IP 反查出的地理位置，本期精确到城市即可 |
| 草稿 | 用户在输入框里打了字但尚未发送的内容。BUG-7 要求它按会话隔离并保留 |