🎯 Seetong 问题雷达 第260期

🔴 问题 1：iOS 登录触发「请求过于频繁」后，滑块验证码弹窗闪现后无法完成验证 ｜ 负责人：欧阳荣、谭伟

1. 现象与覆盖范围

• 现象：用户退出登录后重新用账号密码登录，服务端以 10042911（请求过于频繁，请输入验证码）拦截；随后弹出滑动验证码，用户拖动滑块后界面卡在「验证通过」状态，既不继续登录也不回到可操作状态。
• 涉及反馈：260286（2026-10-29 16:38:26，iOS 8.4.2.3，iPhone 27.2，广东深圳，语言 id_ID，用户 18000233534，原文「安全校验登陆页滑动滑块后卡住」，附带 OBS 附件与 Logan）。
• 设备与版本：iPhone 27.2（iOS 27.2），8.4.2.3；网络为 WiFi（日志 NetworkStatus: 1）。
• 严重度评分：70 / 100（反馈量 10 ／ 共性 20 ／ 关键度 40）。反馈量按「1 名独立用户实测复现 + 神策侧 7 天同错误码 3 641 次」计，单条反馈不放大；关键度取设备登录（40），因为登录是全部监控能力的唯一入口。

说明：本窗口内只有 1 条原声，但下面 Logan 给出一条服务端 → 客户端 → 用户操作的完整时间线，属于可复现证据，不是「用户描述模糊」。

2. 神策证据

• 事件：Login（登录结果）。2026-10-29 手动登录整体成功率 60.21%（119 978 事件 / 72 242 成功），与 10-22 至 10-28 的 58.23%～59.35% 基本持平，没有全量恶化，说明本问题是低频但卡死用户的长尾分支，不是普适登录故障。
• 10042911 在手动登录失败中的绝对量（10-22 至 10-29 逐日）：25 → 3 → 15 → 12 → 15 → 7 → 12 → 7，7 天合计 96 次；与其同族的频控/验证码码位合计 10042911 + 10042912 + 10042913 为 3 641 次（10-29 单日 341 次）。也就是说，绝大多数被频控的用户落到 10042912/10042913 两个码位，而只有落到 10042911 这条分支才会弹滑块。
• 关键结论：「弹滑块」这条分支的入口流量很小（日均约 10 次），但一旦进入就有较高概率无法完成，因此它不会被总量指标发现，只能靠原声 + 日志发现。这也解释了为什么历次登录成功率报表从未暴露该问题。
• 维度限制：神策 Login 事件的 $os / $app_version 在当前项目映射下返回的是字面量（"$os"、"$app_version"），无法按平台/版本切分；本节结论只用「场景 × 错误码 × 日期」维度，平台归因以 Logan 为准。

3. Logan 关键日志

反馈 260286 的 Logan 覆盖 2026-10-29 11:20:53～11:29:42（本地时间，用户 16:38 提交时上传的是这段较早的会话），共 1 312 377 行。关键片段按时间顺序如下：

11:28:46.075  手动点击退出登录
11:28:46.xxx  /seetong-member-auth/logout
11:28:52.970  缓存中是否有登录token: 0 - 是否有用户信息: 0
11:29:04.120  开始账号登录 - 当前的网络状态NetworkStatus: 1 - 账号内容: 15989469220
11:29:04.417  账户名和密码登录接口执行失败 - code: 10042911
11:29:04.417  服务器要求滑动验证码验证 - code: 10042911
              {"code":10042911,"success":false,"msg":"请求过于频繁，请输入验证码","rid":"4bc0412a142b4aed8f3ea8fe6277d34b"}
11:29:04.426  显示滑动验证码弹窗
11:29:04.705  获取滑动验证码接口执行成功（/seetong-client/slide/verify/code）
11:29:41.024  滑动验证码验证完成 - verifyCodeKey: app.ef681260-5743-4d09-b84f-23eead423b6a, encryptedValue前10位: ACwifVEoNw
11:29:41.028  登录请求包含验证码参数 - verifyCodeKey: app.ef681260-5743-4d09-b84f-23eead423b6a
11:29:41.327  账户名和密码登录接口执行成功
11:29:41.327  登录成功 - 已清空验证码参数

这段日志同时给出两个互相矛盾的事实，必须并列写清楚：

1. 客户端这一次是成功的：从弹出滑块（11:29:04.426）到用户拖完滑块（11:29:41.024）共 36.6 秒，滑块下发到登录成功共 36.9 秒，服务端接受了带 verifyCodeKey 的重试。所以「滑块验证码本身不可用」这个说法，在本份日志里不成立。
2. 但这段日志不是 16:38 那次失败：本份 Logan 的最后一行业务日志是 11:29:42.551（长连接连接成功 - 耗时: 0.4 秒），而用户提交反馈是 16:38:26，两者相差 5 小时 9 分钟。也就是说，用户抱怨的「滑动滑块后卡住」发生在这份日志上传之后再没有覆盖到的时段，本份 Logan 不能证明也不能否证 16:38 的失败。

另外两条来自同一份日志、支撑「频控链路由服务端单方面发起」的证据：

• 09:13:02 那次登录（账号 16670540064，NetworkStatus: -1）没有触发滑块，直接 账户名和密码登录接口执行成功；11:29:04 这次是退出登录后 18 秒内立刻重登，才被判定「请求过于频繁」。说明 10042911 的判定与「短时间内重复登录」强相关，与网络状态无关。
• 用户当前环境是国际版测试域名：11:20:53 与 11:28:38 两次冷启动分别指向 app-auth-gbl-test.seetong.com 与 app-auth-test.seetong.com，直到 11:28:52 才切回 app-auth.seetong.com。也就是说同一个账号在十几分钟内跨了三个认证域，这是「短时间内请求过多」的一个合理成因，需要在服务端侧确认频控计数是否跨域共享。

4. 代码定位

• 涉及模块：iOS Classes/Login/（登录页 + 滑块视图 + 登录服务）、Classes/Mine/Controller/STMulAcountManageVC.m（切换账号路径）、Tools/NetworkManager/（请求层统一兜底）。
• 关键类与调用链：

STLoginViewController.requestLogin            (Classes/Login/Controller/STLoginViewController.m:690)
  → STLoginViewController.performLoginRequest (:708)   // 有 verifyCodeKey 时带 verifyCodeKey/verifyCodeValue
  → STLoginService.requestLoginWithParams    (Classes/Login/Services/STLoginService.m:38)
  → onFailure: code == STRequestLoginCodeSafetyVerification (10042911)
  → STLoginViewController.showSlideVerifyView (:641)
  → STSlideVerifyView.showInView:  (Classes/Login/View/STSlideVerifyView.m:46)  // initWithFrame 内即 requestVerifyCode
  → completeSlideVerification → 延迟 1.0s → encryptVerifyCodeValue → 延迟 0.5s → delegate 回调 → dismiss

• 关键分支与可疑点（按可疑程度排序，均为代码推断，尚无 16:38 现场日志佐证）：

• 同一缺陷的第二处入口：STMulAcountManageVC.m:151-186 是切换账号的安全校验分支，逻辑与登录页几乎重复（同样 showSlideVerifyView + exchangeAccount 重试），但没有 performLoginRequest 的参数兜底。修复必须两处同改，否则切换账号路径会留下同样的坑。

5. 上游配置疑点

• 11:28:38 与 11:20:53 两次冷启动的 userDomain 分别是 app-auth-test.seetong.com 与 app-auth-gbl-test.seetong.com，11:28:52 切回 app-auth.seetong.com。同一台设备、同一账号在十几分钟内跨三个认证域。
• 需要服务端确认：10042911 的计数键是「账号 + 域名」还是「账号」，以及 10042912/10042913 与 10042911 的阈值关系。若计数跨域共享而验证码只在 10042911 分支下发，就会出现「用户其实没超频，但一直被要求验证码」的错判。

6. 根因结论

• 置信度：🟡 中（原声 + 代码链路完整，但缺少 16:38 那一次失败的现场日志，客户端具体在哪一步卡住仍是推断）。
• 一句话根因：用户被 10042911 频控后进入滑块验证分支，而该分支在 iOS 登录页与切换账号页存在「父视图重建 / 两层延迟回调无取消 / 缺参数重试」三处竞态，任一处命中都会让滑块无法完成，用户只能退出重来。
• 关键证据链：Logan 11:29:04.417 → 11:29:41.327 的完整成功链路证明「滑块可用、验证码参数被服务端接受」；同时间段频繁切换认证域证明频控被误触发的可能；神策 10042911 7 天 96 次、同族码位 3 641 次证明这是低频长尾分支，恰好解释了为何长期未被总量指标发现。

7. 建议下一步

• 归属：iOS 登录模块（Classes/Login/ 主责），服务端认证与频控协同。
• 优先处理项：

1. 给 STSlideVerifyView 增加完成回调单飞 + 视图存活校验（window != nil 才回调），并把两层 dispatch_after 合并为一层带取消令牌；requestVerifyCode 失败不要直接 dismiss，改为在弹窗内展示重试按钮并保留用户输入。
2. 服务端回查 rid=4bc0412a142b4aed8f3ea8fe6277d34b 与 10042911 的计数键，确认跨认证域是否共用计数器；若是，客户端在域名切换后应清空频控缓存。

• 验证方法：在 iPhone 27.x + 8.4.2.3 真机上，用「连续 3 次错密码触发频控 → 弹滑块 → 飞行模式 5 秒 → 关闭飞行模式」构造弱网，覆盖「频控拦截 / 验证码过期 / 用户取消 / 弱网超时」四类场景各 20 次，要求全部要么成功登录、要么给出可重试的明确提示，不允许停在无响应状态。

🟠 问题 2：Android 8.4.1.6 卡回放时间线跳动、切换通道丢失当前时间位置 ｜ 负责人：张威

1. 现象与覆盖范围

• 现象：卡回放页的时间轴游标「老是跳动」，找准时间点后切到另一个摄像头，时间位置被重置，需要重新找；时间轴放大缩小时刻度和色块位置不稳定。
• 涉及反馈：260241（2026-10-29 11:51:01，Android 8.4.1.6，OPPO PKH110，河北沧州，原文「回放录像的时候，时间线老是跳动。找准时间后切换另一个摄像头又得重新找时间。时间线放大缩小的时候也不稳定」）。
• 与上期的关系：第259期 260052 / 260048 / 259948（HONOR MEY-AN00，广东）已就「回放时间轴显示不对」立案，本期新增样本是不同用户、不同机型、不同地区，且新增了「切通道丢时间」和「缩放不稳定」两个行为描述。
• 严重度评分：63 / 100（反馈量 10 ／ 共性 20 ／ 关键度 30）。按 24h 去重规则，反馈量按本期新增 1 名独立用户计，不把上期样本并入。

2. 神策证据

• 事件：DeviceVideoPlayback（回放播放结果）。2026-10-22 至 10-29 期间该事件日量在 1 200 万以上且平稳，没有出现与时间轴相关的可用字段（事件不含 timeline / seek 类的结构化维度）。
• 事件：MonitorFrameResult（出图结果）。10-29 的 3 510 万次中成功率 97.38%，与 10-22 至 10-28 的 97.09%～97.35% 一致，回放/预览出图侧没有异常。
• 因此本问题的「时间轴跳动 / 切通道丢时间」在神策侧完全不可观测，只能靠原声与代码；这也是它连续两期只能停在「代码可疑」层面的原因。

3. Logan 关键日志

• 260241 的 loganFileDownloadUrl 有值，fileUrl 也存在（用户上传了附件），但本期未取得可读的游标/seek 相关日志（Android 侧该类日志落在 KMP 层，需按 PlaybackTimeline / openSelectedChannel 定向抓取）。本节标注为「Logan 待补证」，不用推测填补。
• 需要下一次抓取的关键词：openSelectedChannel、sliderTimestamp、mCurrentPlayTime、setPlayPosition、seek、PlaybackPage、onScale。

4. 代码定位

• 归属：KMP 卡回放页（Seetong-App-AI 共享层，PlaybackPage / 时间轴组件），Android 侧 LibImpl 承接 MSG_REPLAY_SET_POSITION。
• 与既有任务的关系：T-20260922-170415-9496（排查 Android 卡回放拖动卡顿与时间跳转异常）已经写明修复方向——在 openSelectedChannel 前快照 sliderTimestamp / mCurrentPlayTime / 播放状态，新通道录像索引返回后恢复同一时间；无录像时定位最近片段并提示。本期证据完全支持该方案（用户明确描述「切另一个摄像头又得重新找时间」），因此不新建任务，只更新该任务的 next_action。
• 缩放不稳定的可能锚点（需读代码确认）：时间轴缩放时若同时重算 slider 的 min/max 与刻度标签，容易出现「同一个时间点在两种缩放下映射到不同像素」的现象；第259期已指出 NVR 分段比例与刻度换算可能用了两套比例。

5. 根因结论

• 置信度：🔴 弱（仅 1 条原声 + 上期同主题样本 + 代码方向，无本期 Logan 直证）。
• 一句话根因：卡回放页在通道切换与时间轴缩放两条路径上都没有把「当前时间位置」作为状态快照保存与恢复，导致每次交互都从新索引重算时间轴。
• 关键证据链：用户描述与 T-20260922-170415-9496 的代码方向一致；神策 DeviceVideoPlayback 与 MonitorFrameResult 均正常，排除了「播放失败被误认为时间轴错」这一解释。

6. 建议下一步

• 归属：KMP 回放组（主责），Android 承接层协同。
• 优先处理项：按 T-20260922-170415-9496 的方案实现时间位置快照与恢复；同时为时间轴组件补一条 zoomChanged(oldScale,newScale,centerTimestamp) 的 Logan，否则同类问题永远无法量化。
• 验证方法：Android 8.4.1.6 + NVR 多通道场景，来回切换通道 20 次、时间轴缩放 20 次、跨录像间隙 10 次，要求切回后时间位置偏差 ≤ 1 个刻度。

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

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

平台分布（非网络类）：HarmonyOS 1.1.2.3 31 条、Android 8.4.1.6 16 条、Android 8.4.4.1 3 条、iOS 8.4.1.6 2 条、iOS 8.4.2.3 1 条。HarmonyOS 占比高但集中在离线/回放存量线索，本期未出现新的跨用户共性。

应用市场反馈（2026-10-29 00:00–23:59）

差评原文摘录：本窗口无采集到的评论。

采集状态：华为应用市场 0 条｜应用宝 0 条｜App Store 失败（Apple 限流，未配 ASC Key）｜Google Play 失败（未配置代理）｜待导入：荣耀应用市场 / vivo 应用商店 / OPPO 软件商店 / 小米应用商店。

数据源状态

心愿单亮点

待补证

• 问题 1 缺 16:38 现场日志：260286 的 Logan 止于 11:29:42，距提交 5 小时以上。下期需通过客服回访索取 16:38 前后的录屏或重新抓取一次完整 Logan；在此之前「滑块点不动」只能停在代码推断。
• 服务端频控计数键未确认：10042911 是否按「账号 + 认证域」计数，直接决定是否需要客户端在切域后清缓存。需要服务端同学回查 rid=4bc0412a142b4aed8f3ea8fe6277d34b。
• 问题 2 无本期 Logan：需在 Android 8.4.1.6 上按 openSelectedChannel / sliderTimestamp / setPlayPosition 定向抓取，否则该问题只能继续沿用第259期的代码结论。
• 神策平台维度失效：Login / MonitorFrameResult 的 $os、$app_version 返回字面量，导致无法按平台/版本切分错误码。建议由数据侧核对事件属性映射，否则后续同类问题都要靠 Logan 单点取证。
• 应用市场渠道长期盲区：App Store 未配 ASC Key、Google Play 无代理、四家手商店未导入，应用市场侧仍完全没有信号。

下一期 = 第261期 = 2026-10-30-H17.md（明天下午 17:00；窗口 2026-10-29 17:00～2026-10-30 17:00）