🎯 Seetong 问题雷达 09:00 第233期

🔴 问题 1：iOS / Android 8.4.1.6「报警回放看不了」跨端聚集（4 机型 / 4 地区 / 凌晨 3 小时窗口） ｜ 负责人：唐胜、欧阳荣、位冬、陈宝旺

1. 现象与覆盖范围

• 现象描述：用户从报警消息进入回放，界面打不开或看不到画面；部分用户同时描述进入消息页后界面卡住、无法操作。所有反馈都强调「升级后」出现，未升级前正常。
• 涉及反馈：257345、257346（iOS 8.4.1.6 / iPhone 17.1.1 / 山东聊城冠县，同一用户 05:13:44 与 05:14:17 连提 2 次）、257341（Android 8.4.1.6 / vivo V2561A / 刚果金金沙萨）、257344（Android 8.4.1.6 / vivo V2548A / 江苏宿迁泗阳）、257343（iOS 8.4.1.6 / iPhone 27.0 / 江苏徐州贾汪，原话「看消息…动都动不了」）
• 覆盖维度：2 平台（iOS + Android）× 4 机型 × 4 地区（山东 / 江苏 / 安徽 / 刚果金）× 1 版本（8.4.1.6）＝ 4 个维度
• 时间聚集性：5 条全部落在 2026-10-15 02:01 ~ 05:14 的 3 小时 13 分内
• 对比参照：同窗口 Android 8.4.1.6 另有 257274（安徽亳州，iOS，19:35）、257252（陕西西安，Android，18:05，仅报「加减时间段反应慢」）
• Logan 可用性：5 / 5 全部提供 Logan（本窗口 HarmonyOS 反馈则 16 / 16 无 Logan，形成鲜明对比）
• 严重度评分：66 / 100（反馈量 20 / 共性 30 / 关键度 30）
• 反馈量 20：窗口内 5 条同义反馈（3～5 条档）
• 共性 30：涉及 2 平台 × 4 机型 × 4 地区（≥3 维，满分）
• 关键度 30：录像回放类，取 30（低于设备掉线/远程查看的 40）

2. 神策证据（核心数据源）

• 事件可用性核验：Login 事件近 8 天有稳定触发（10-08 ~ 10-14 日均为 76.6 万 ~ 86.2 万次 / 53.8 万 ~ 60.8 万用户），说明神策取数链路正常，下面的缺口是埋点覆盖问题而非查询问题

• 关键缺口：报警回放链路未找到可用的服务端失败分流事件。本期尝试以 Login 的 login_fail_type 做维度校验时，神策直接报 ImpalaSQLException: Could not resolve column/field reference: 'login_fail_type' —— 该字段在服务端不存在。因此问题 1 无法给出 error_code 分布与漏斗断点，这是本期最重要的证据边界，已在「待补证」写明补法。
• 趋势判断：无法下趋势结论（缺少对应事件），不得用 Login 的量级代替回放链路。

3. Logan 关键日志（核心数据源）

• 反馈 257346（iOS，1106607 bytes / 30680 行）：日志起始 2026-10-11 10:07:45，命中内容集中在 10-11 与 10-16 之外的预置窗口，可见 AlarmMessagePage / MessageCenterPage 的 kuikly 性能行（Memory in use: 38.673MB）、TPS_MSG_RSP_ADDWATCH 握手回执（error:0）、InitDecodePortLog 一次解码端口异常：

> [L608] InitDecodePortLog: uid:31513316 init decode video param error! Video Params - width: 0, height: 0, framerate: 0, nMediaType: 0x0000
—— 该行说明存在一路取流拿到了全零的视频参数，但发生在预览链路且在本次日志早段，不能直接归因到报警回放入口。

• 反馈 257344（Android，108169 bytes / 3901 行）：日志起始 2026-10-15 01:10:35，是本次唯一覆盖凌晨时段的样本，可见 AlarmMessagePage 首屏加载全链路成功：

> [L556] AlarmMessagePageVM:alarm list updated, date=2026-10-15, ..., hasMore=false, count=100
> [L560] AlarmMessagePage:loadInitialData network-first success elapsedMs=144 rowCount=2
—— 消息页本身加载正常（144 ms），queryAlarmMessages 一次拉回 1 条（itemCount=1）；日志未见任何 onReplayError / play failed 或回放启动失败记录，说明该用户在本段日志内没有进入回放页（或回放页无日志上报）。

• 反馈 257343（iOS，1019001 bytes / 558880 行）：可见 AlarmMessagePage 的 kuikly 页面创建（[KLog][AlarmMessagePage]:startObserveOnlineAlarmMessages source=created）、queryAlarmMessages success ... itemCount=100 与 MessageThrottle reloadTableView，未见卡死堆栈或主线程阻塞证据。
• Logan 结论：3 份样本都没有捕获到报警回放的失败调用，失败链路发生在日志覆盖时段之外。因此本问题的根因不能从 Logan 直接读出，置信度只能给「中」。

4. 代码定位（详细）

• 涉及模块：KMP 回放页（Android 宿主）/ iOS 消息模块
• 关键类与锚点：
• Android 报警回放入口：AlarmBridgeApiImpl.kt:241-264（openPlaybackPage）→ PlaybackPageRouter.kt:44-80（openPlaybackPage）→ :58 的跨端开关 shouldOpenCrossPlatformPlayback() → openKmpPlaybackPage
• 跨端开关判定：PlaybackPageRouter.kt:88-96

val config = Global.getUserConfig() ?: return false
val configText = config.crossPlatformConfig?.takeIf { it.isNotBlank() } ?: return false
return JSONObject(configText).optBoolean("and", false)

• 关键缺陷锚点：openKmpPlaybackPage（:101-141）构造页面参数时，isCloudReplay 一行被注释掉：

put("fromAlarmReplay", fromAlarmReplay)
put("alarmReplayTime", alarmReplayTime)
//put("isCloudReplay", isCloudReplay)   // ← 被注释

而 KMPBridgeModule.kt:626 读取该字段并留了默认值 true：

isCloudReplay = userData?.optBoolean("isCloudReplay", false) ?: false,

→ 参数在 KMP 路径上被静默丢弃，回放类型退化为默认值，与原生 legacy 路径（PlaybackPageRouter.kt:156-163 明确 putExtra(Constant.EXTRA_IS_CLOUD_REPLAY, isCloudReplay)）行为不一致。

• 回放启动：RecordPlayerView.kt:245（recordPlayCallback?.onStartReplay(device)）与 :249-258（IO 线程 startNvrReplay + 重试 + onReplayError）
• 底层调用：LibImpl.java:803-840（startNvrReplay → P2PNvrReplayByTime / LocNVRReplayByTime）
• 调用链：AlarmFragment2.java:1839 / MainActivity2.java:1411 → PlaybackPageRouter.openPlaybackPage → openKmpPlaybackPage → Kuikly PlayBackPage → KMPPlayBackVideoView.playVideoByTime（:223-229）→ RecordPlayerView.startReplay → startNvrReplay
• 关键分支：recordType == 0 时被改写为 Integer.MAX_VALUE（LibImpl.java:826-828）；枪球设备 audioEnable 走 isGunDevice 分支 —— 这两条路径都可能让"报警录像"这类特定录像类型的检索范围与预期不一致
• 修复方向锚点：

1. 优先：恢复 PlaybackPageRouter.kt:120 的 isCloudReplay 透传（或明确 KMP 侧不再需要该参数并删除消费点，二者必须一致）
2. KMPBridgeModule.kt:626 的默认值需与原生路径一致，避免"字段缺失 = 默认 true"这种隐式语义
3. 报警回放入口需补失败可观测性：openAlarmPlaybackPage 目前失败只写 Log.e（KMPBridgeModule.kt:633），未接埋点

5. 根因结论

• 置信度：🟡 中
• 一句话根因：报警回放在 Android 上已切到 KMP 路径，但 KMP 路径丢掉了 isCloudReplay 参数（PlaybackPageRouter.kt:120 被注释），与原生路径行为分叉；叠加该链路没有任何服务端失败埋点，导致用户看到"看不了"却无从定位。
• 关键证据链：反馈跨端跨地域聚集（5 条 / 4 机型 / 4 地区 / 1 版本）+ 代码层面参数透传缺失（已定位到行）+ 神策字段缺失导致失败分布不可查 —— 三者互相印证的是「可观测性缺口」，而不是某一处崩溃。
• 明确不成立的推断：不得据此认定「8.4.1.6 回放必然失败」；257344 的 Logan 显示消息页加载正常（144 ms），说明不是全链路不可用。

6. 建议下一步

• 分配给：唐胜（KMP 回放页 owner，RecordPlayerView.kt / KMPPlayBackVideoView.kt 近期提交者；PlaybackPageRouter.kt 亦由其 2026-07-31 feat:优化回放页面跳转数据内容 引入）
• 优先处理项：

1. 复核 PlaybackPageRouter.kt 的 isCloudReplay 为何被注释，确认是临时调试残留还是有意为之；给出恢复或显式废弃的结论
2. 为报警回放入口补失败埋点（openAlarmPlaybackPage 失败分支目前只在 Log.e）

• 验证方法：回归用例覆盖「报警消息 → 卡回放」在云回放与本地录像回放两种类型下的跳转参数一致性；回访 257345/257346（同一用户，留存意愿强）

🟠 问题 2：iOS 8.4.1.6 重置密码失败并回显原始错误码 30000126 ｜ 负责人：位冬、谭伟、许源、唐胜

1. 现象与覆盖范围

• 现象描述：用户一键重置密码失败，界面直接弹出「重置密码失败(30000126)」——括号里是服务端原始错误码，未翻译成用户可理解的文案。
• 涉及反馈：257356（iOS 8.4.1.6 / iphone 26.3.1 / 山东潍坊 / 06:07:26，带 Logan 与文件日志）
• 严重度评分：60 / 100（反馈量 10 / 共性 20 / 关键度 30）
• 反馈量 10：窗口内 1 条直接反馈
• 共性 20：涉及 1 机型 × 1 版本 × 1 地区，但神策侧显示跨版本高频（见下），故不取最低档
• 关键度 30：账号可恢复性属于中高关键路径（用户无法自行找回密码 = 账号直接不可用）

2. 神策证据（核心数据源）

• 事件：ForgetPassword（忘记密码全流程埋点，STResetPasswordSensor.m:150 上报）
• 近 7 天（2026-10-08 ~ 10-14）整体量：

• error_code=30000126 分布（近 7 天累计）：996 次 / 192 个用户
• 对照其它错误码同窗口量级：30000211 验证码错误 3,580 次 / 1,425 用户；30000212 验证码过期 1,408 次 / 380 用户；30000203 账号未注册 22,157 次 / 11,432 用户
• 即 30000126 不是尾部偶发，而是稳定占比的错误类型（约占非 200 错误的 2.6%）
• 重置方式分布（近 7 天）：一键重置 47,050 次 / 36,090 用户；手机号重置 59,058 次 / 39,179 用户；邮箱重置 1,690 次 / 602 用户

—— 一键重置占总量约 43%，而 30000126 正是一键重置专属错误码（见下），影响面不可忽略

• 趋势：7 天内日活稳定（9,974 ~ 11,012 用户），未见爆发，属长期存在的稳定缺陷而非新版本回归

3. Logan 关键日志（核心数据源）

• 反馈 257356（iOS）：该用户提供 OBS 文件日志（1498424 bytes），日志起始 2026-02-07 11:32:15
• 可见的关键上下文（同一账号 18206441777 / user_id 40746506 在多个时段反复冷启动）：

> [L233] 2026-02-11 20:41:40.732 Seetong_tps[6470:2309899] -- 登录流程 -- AppDelegate -- configRootVC - didFinishLaunchingWithOptions --
> [L282] 2026-02-11 20:41:40.971 ... 收到刷新token回调 - 数据不包含 NULL 终止符，可能引发错误。

• 重要边界：日志时段为 2026-02 至 2026-10 的长跨度历史堆积，未直接命中 2026-10-15 06:07 的这次重置密码请求，也没有命中 30000126 的失败响应体。因此本问题的 Logan 只提供了环境上下文，未提供失败瞬间证据。
• 可用的旁证：[L52] 与 [L282] 两处一致的 数据不包含 NULL 终止符，可能引发错误。 提示 token 回调解析存在已知告警，官方 SDK 注释自身即标注"可能引发错误"，与 token 过期类错误同源。

4. 代码定位（详细）

• 涉及模块：iOS Classes/Login/Controller、Tools/TPS_CommonUtil；Android login/src/main/java/com/seetong/login/utils
• 关键常量定义：
• iOS：Tools/NetworkManager/STResponseModel.h:88 STRequestRegisterErrorCodeTokenExpire = 30000126, // token已过期
• Android：login/src/main/java/com/seetong/login/utils/AccountCodeUtils.kt:95 const val ERROR_ONE_KEY_TOKEN_EXPIRE = 30000126，注释「本机号码-授权token已过期」
• 调用链（iOS）：

STForgetPwdViewController.mm:711（kAPIResetPwdNumberCheck 本机号码校验）→ onFailure → :734-745 拼 forget_reset_password_fail(%zd) → STLogManager handleErrorWithCode: 上报
STLoginViewController.m:277（同接口，登录页入口）→ onFailure → :303-309 同款拼接
STOneKeyResetPwdViewController.m:138（kAPIResetPwdLocalNumber 一键重置提交）→ onFailure → :175-182 同款拼接
TPS_CommonUtil.m:281（getLocalRegisterCodeErrorText）把该码映射为 login_by_thirdsoft_err_invalid_code_token
zh-Hans.lproj/Localizable.strings:1167 → "通过code获取的token失效"

• 调用链（Android）：

AccountCodeUtils.kt:488 ERROR_ONE_KEY_TOKEN_EXPIRE -> tips = context.getString(R.string.login_by_thirdsoft_err_invalid_code_token)
:505 return "$tips($code)" ← 错误码被无条件拼进用户文案

• 关键分支：iOS 侧 getForgotPwdErrorCodeText:（TPS_CommonUtil.m:388-407）没有覆盖 30000126 分支，落到 else 兜底：

return [NSString stringWithFormat:@"%@(%zd)",STRING(@"network_weak_hint", @""),errorCode];

该兜底在语义上把"授权 token 过期"误报为"网络问题"，与 STOneKeyResetPwdViewController.m:175-182 走 forget_reset_password_fail(%zd) 的路径文案不一致（同一错误码在不同入口显示不同标题）。

• 修复方向锚点：

1. TPS_CommonUtil.m:388-407 增加 30000126 显式分支，给出可操作文案（如「本机号码校验已过期，请重新获取」）并提供重试入口，而非仅提示失败
2. 底层修复：一键重置依赖第三方闪验 SDK 的授权 token，STLoginViewController.m:249 已存在 innerError 处理与 [[UserClient shareUserClient] init_fc] 重新初始化逻辑，但 token 过期时没有触发重新初始化，只是弹提示 —— 这是让用户「卡死在同一个错误」的直接原因
3. Android 侧 AccountCodeUtils.kt:488 同上，需统一跨端文案与重试行为

5. 根因结论

• 置信度：🟡 中
• 一句话根因：一键重置密码依赖第三方闪验 SDK 的授权 token，token 过期（30000126）时 App 只弹原始错误码、不重置校验链、不给重试入口，用户被永久卡在同一失败态；且 iOS 兜底分支还把该错误误述为"网络问题"。
• 关键证据链：反馈原文直接携带错误码（用户可见）+ 神策 ForgetPassword.error_code=30000126 近 7 天 996 次 / 192 用户（长期稳定）+ 代码两端均确认 (%code) 拼接展示 —— 三条独立证据互相印证。
• 保留意见：Logan 未命中失败瞬间，无法排除"该用户另有并发问题"；但代码与埋点证据已足以定性。

6. 建议下一步

• 分配给：位冬（STForgetPwdViewController.mm / STOneKeyResetPwdViewController.m / 忘记密码埋点近期提交者）；Android 侧 唐胜（AccountCodeUtils.kt 的 30000126 分支由其 2026-03-12 引入）
• 优先处理项：

1. iOS 补 30000126 的显式文案 + 重试入口，消除 network_weak_hint 误述
2. 一键重置失败时触发闪验 SDK 重新初始化（复用 STLoginViewController.m:249 已有模式），而不是直接终止

• 验证方法：构造 token 过期场景（等待或篡改本地 token 缓存）走一键重置，确认提示可理解且可重试成功；上线后观察 ForgetPassword.error_code=30000126 的日计数是否下降

本期扫描全量（全部沉淀到知识库）

Markdown 里保留全部反馈（含 -102 等网络问题）；HTML 呈现时渲染器会自动折叠 🟣 普遍性网络问题

（含中/英/俄/法/西/葡/土/阿/日多语言网络提示模板），只展示更有价值的条目，无需在本段手工删减。

已折叠 2 条普遍性网络问题（含 -102/-101/-1002 与中/英/俄/法/西/葡/土/阿/日多语言网络提示模板，如 Проверьте телефонную сеть、Please check your mobile network）；全量明细见同名 Markdown 知识库。

本期重点反馈明细（非网络类，按时间倒序）

HarmonyOS Logan 覆盖情况（第 12 期连续零覆盖）
本窗口 HarmonyOS 反馈 16 条，Logan 提供数 0 条（0 / 16）。这已是连续第 12 期 0 覆盖，T-20261008-142800-9c1e 建议由 P1 提级为团队级阻塞项——HarmonyOS 侧任何问题都只能靠文案聚类，无法做根因分析。

任务账本联动

说明一：问题 1 未新建任务，因其作为「KMP 回放页参数透传不一致 + 回放链路缺埋点」的新形态，与 T-20261014-090647-bbbe（失败事件竞态）根因不同但同属 KMP 回放链路，本期按独立观察项记录，下期若再现即独立建单。

说明二：问题 1 与 T-20260926-170258-576a（回放熄屏）虽同窗口出现于 257344 同一条反馈，但一个是"看不了"、一个是"熄屏"，按 skill 规则分开归属，未合并。

数据源状态汇总

心愿单亮点

待补证

1. 报警回放链路缺埋点（问题 1 最大盲区）：需在 openAlarmPlaybackPage 失败分支（KMPBridgeModule.kt:633）与 startNvrReplay 返回值（RecordPlayerView.kt:249-258）接入服务端可查的埋点，否则下期仍无法给出失败分布与漏斗断点。
2. Logan 时段与反馈时刻不重合：257346 / 257343 / 257356 三份日志均未覆盖失败瞬间。下次 run 应优先对反馈时间后 30 分钟内再次上传日志的用户抽样，或推动 Logan 上报策略改为"反馈提交时强制追加最近 10 分钟缓冲"。
3. isCloudReplay 参数注释的意图未确认：PlaybackPageRouter.kt:120 被注释是临时调试还是有意废弃，需 owner 确认后才能定修复方案。
4. login_fail_type 字段不存在：已确认服务端无此字段，后续不要再以该字段做维度拆分；如需登录失败分流，应先确认真实字段名（可参考 AccountCodeUtils.kt 中的错误码常量表）。
5. HarmonyOS Logan 零覆盖连续 12 期：需服务端 / 客户端共同定位上报链路断点，已建议提级。
6. 问题 2 的失败瞬间证据：建议回访 257356 用户（山东潍坊 / iOS 8.4.1.6），在其复现一键重置时即时上传日志。

下一期 = 第234期 = 2026-10-15-H17（今天下午 17:00；窗口 今日 09:00 ~ 17:00）