知页 Internal system error（重装后自动登录）

1. 问题背景

卸载并重新安装 App 后，通过「记住密码」等方式自动恢复登录，进入底部 Tab「知」时，知主页（感悟列表）中央直接显示英文 Internal system error，列表无法加载。其他 Tab 是否同时异常，取决于首屏是否同样请求关系库（本文以知主页为入口）。

另需区分两类现象：云侧返回错误，与 首屏失败后切 Tab 再回来仍占位错误（旧版前端未再次请求）。二者排查路径不同。

2. 问题列表

2.1 知主页数据加载失败，界面展示 Internal system error

根因（链式证据级定位，最多 3 轮；证据不足则加日志）

1. why1 — 为什么会出现这句英文？
   ZhiHomeContent 在 user_insights 请求失败时把 err.message 原样写入界面；该文案与 CloudBase 关系库 HTTP API 对 SYS_ERR / HTTP 500 的说明一致，可认定响应经 SDK 透传为网关侧「服务端内部错误」口径，而非典型 401/403 提示。
2. why2 — 为何在「重装自动登录后进知页」易暴露？
   首屏在 waitForAuthToken() 之后立刻对 user_insights 做带 user_id 的分页查询，属于冷启动后较早的带登录态读请求。具体是云侧短时故障、SYS_ERR，还是会话 / token 就绪与首屏叠在一起，需 Metro、[cloudbase] 日志与控制台 RDB 记录对照，不在此多轮展开。
3. why3 — 为何曾出现「切 Tab 再回来仍一直 Internal」？
   旧版 useFocusEffect 在无模块缓存时直接 return，首屏失败不写缓存，useEffect 又不随切 Tab 重跑，错误会一直占位（与云是否恢复无关）。已改为：同用户第 2 次起 focus 且无 / 过期缓存时补拉，并与下拉刷新一起作为明确恢复路径。
   （user.id 与 token 主体极端不同步等推断，证据不足则靠 [Auth] / [AuthProbe] 与加日志，不另开轮次。）

方案（每项各列一条）

短期方案

• 做法：用户切换 Tab 再回「知」、列表下拉刷新；仍失败则杀进程或退出再登录。开发侧查看 Metro 中 [ZhiHomePage] 加载失败 与 [cloudbase] / [RDB]，控制台对照关系库 / 网关日志时间与错误码。
• 优点：成本低，易区分瞬时故障与会话问题。
• 缺点：不落日志则根因仍可能说不清。

长远方案

• 做法：有实测竞态时再收紧「登录完成 → 首屏 RDB」的 token 就绪；将 SYS_ERR 等在 UI 换成简短中文并尽量带可观测字段；不做首屏无感多次自动重试，以「再进 Tab + 下拉刷新」为主恢复手段。
• 优点：行为可预期，接口压力可控。
• 缺点：偶发抖动依赖用户多操作一次或依赖 focus 补拉。

采纳方案

• 已采纳：修复 useFocusEffect（无缓存时不永久跳过补拉；首焦仍由 useEffect 拉首屏，避免双请求）。
• 不采纳：首屏自动退避重试连打。
• 云侧：仍以控制台与 RDB 日志为最终裁决。

补充用例

• 卸载重装 → 仅自动登录 → 冷启动进「知」是否易复现。
• 手动重登后是否消失（区分会话与环境）。
• 弱网连试多次，区分抖动与稳定 Bug。
• 首屏失败后切走再切回，是否重新请求（验证 focus 逻辑）。

3. 小结

• 界面上的 Internal system error 来自关系库 REST 层 SYS_ERR（500）类响应，经 SDK 进入 error.message，由知主页原样展示。
• 重装后自动登录使 user_insights 首读成为高信号排查点。
• 旧版「切 Tab 仍报错」来自 focus 在无缓存时提前 return，已修复。
• 后续体验优化优先：可观测性与错误中文案，而非首屏静默多次自动重试。