Seetong · Report

🎯 Seetong 问题雷达 17:00 第250期

时间窗口：2026-10-23 09:00:46～2026-10-23 17:01:00（Asia/Shanghai）

📌TL;DR 核心要点

  • 🟠 第三方授权码校验失败 30100225 在 8 小时内出现 188 次、影响 107 名用户，覆盖 Android、iOS、HarmonyOS 和多个在网版本。反馈 259063 的 Logan 证明请求携带非空微信授权码后，服务端仍返回“授权码校验失败”。失败链路没有可恢复的一次性授权与重新授权机制，现为持续性长尾问题，沿用任务 T-20261018-090804-7ee8。
  • 259063：2026-10-23 13:25，iOS 8.1.2.4、iPhone、iOS 26.6、安徽。用户反馈原文为“登录失败(30100225)。上传错误日志以便更快发现并修复问题。”
  • Sensors 显示，同一时间窗口内 Login 共 332,904 PV / 245,068 UV，其中 error_code=30100225 为 188 PV / 107 UV。按事件量计算失败占比 0.056%，按去重用户计算占比 0.044%。

🔥最近一个月 Top 问题

按严重度与复发期数排序，已把跨期同类反馈归集；负责人由问题代码锚点对应的 Git 提交历史（blame / 近期主要提交者）反查；数据窗口：最近 30 天（截至 2026-10-23）。

#问题（严重度降序）严重度平台版本负责人问题原因
1HarmonyOS `1.1.2.3` 多用户离线与核心视频链路失效
21 期 · 175 条反馈
100Android · HarmonyOS1.1.1.11 / 8.4.1.6 / 1.1.2.3唐胜、陈宝旺、冉博麟、谭伟HarmonyOS 客户端把 P2P 瞬时离线写成本地持久状态，并在后续在线判断中优先使用这个旧值，可能导致设备已恢复在线却仍显示离线；回放离线态和播放错误透传不足则放大了用户的“看不到画面”体验。
2Android 与 iOS 8.4.1.6 报警功能突然失效与通知不达
1 期 · 3 条反馈
90Android · iOS8.4.1.6唐胜、许源现有客户端样本表明 Android 通知权限与 token 注册均成功，故障更接近“服务端未生成报警或推送任务未送达”，但神策缺少报警生成与推送到达事件，iOS 样本又混合了通知权限关闭，当前不能完成单点定因。
3HarmonyOS 画中画状态导致切换设备后仍显示前一路画面
1 期 · 3 条反馈
90HarmonyOS1.1.1.11 / 1.1.2.3张跃译多个 HarmonyOS 画面共享一个无代次、无串行化、无旧控制器清理的 PipManager，切换设备时旧创建任务和新选择竞争，最终把第一路 XComponent、savId 或恢复状态保留下来。
4升级后回放体验整体退化
4 期 · 18 条反馈
85Android · iOS8.4.1.6 / 8.3.14.2唐胜、许源、欧阳荣、谭伟8.4.1.6 对回放链路做了多处改动（时间条 UI、通道切换进度对齐、报警-录像联动），导致回放体验多点退化；Logan 显示取流层无崩溃，问题在"UI/状态对齐 + 报警录像关联"而非连接失败。
5KMP 回放页未申请屏幕常亮，回放中手机自动息屏
11 期 · 29 条反馈
84Android · HarmonyOS8.4.1.6 / 8.4.1 / 8.4.2唐胜、陈宝旺、许源、张威KMP 回放页的屏幕常亮能力已在代码中完整实现（KMP 公共层 → 桥接层 → Android 宿主层齐备），但承载该实现的提交只落在 feature_v8.4.2 一条分支上，feature_v8.4.4、master、hotfix_v1.1.1 全部不含，因此所有已发布版本（Android 8.4.1.6 / HarmonyOS 1.1.1.11）在运行时都走不到 FLAG_KEEP_SCREEN_ON，回放过程中发生系统级息屏。
6Android 实时预览无首帧却被标记为“视频播放中”，并无限重试
5 期 · 12 条反馈
80Android · iOS8.4.1.6 / 8.4.1.4唐胜、张威、谭伟、欧阳荣预览页把“取流请求已提交”或“设备在线状态消息”误当成播放成功，而没有把首帧到达作为唯一成功门禁；add_watch_result=-1 后仍持续 10 秒重试并显示“视频播放中”，导致用户长时间等待且无法获得明确失败反馈。
7SD 卡跌至不可读写或反复未初始化，录像回放被直接阻断
3 期 · 9 条反馈
80Android · HarmonyOS · iOS8.4.1.6 / 1.1.1.11唐胜、张威、陈宝旺设备上报的 SD 卡状态在 258245 中持续处于未初始化／格式化中，在 258173 中由正常可读写跌至不可读写；App 按协议正确展示异常，根因更可能在 SD 卡、卡槽／供电、设备存储控制器或固件挂载逻辑，而不是 KMP 页面误报。
8iOS `8.4.1.6` 云回放卡顿，首帧与失败状态可能被提前结算
2 期 · 8 条反馈
80Android · iOS8.4.1.6 / 8.3.11.3 / 8.4.106陈宝旺、欧阳荣、谭伟iOS 云回放容器允许解析完成后在 1.2 秒无首帧时提前向 KMP 返回成功，同时把 IJK 播放错误与正常结束合并处理，导致页面对真实卡顿、缓冲超时或解码失败缺少准确状态和可回溯证据；这是高度可疑的共同客户端缺陷，但仍需复现确认其是否为 3 名用户的直接主因。
9iOS 8.1.2.4 微信登录授权码重复提交触发 30100225
1 期 · 3 条反馈
80iOS8.1.2.4 / 8.1.204 / 8.4.106待定微信回调与恢复登录没有一次性 state、幂等锁和授权码消费机制，重复回跳或重试会把同一个单次授权码再次发给服务端，服务端以 30100225 拒绝后客户端仍保留旧状态。
10iOS 老版本微信登录空授权码触发 30100222
1 期 · 1 条反馈
80iOS8.1.3.5 / 8.1.305 / 8.1.503位冬微信授权回跳在当前旧版 iOS 上返回了空 code，客户端没有把它视为失败边界，仍向服务端提交空授权码，最终稳定触发 30100222。

🟠 问题 1：跨端 30100225 第三方授权码校验失败持续影响登录

现象与覆盖范围

  • 259063：2026-10-23 13:25，iOS 8.1.2.4、iPhone、iOS 26.6、安徽。用户反馈原文为“登录失败(30100225)。上传错误日志以便更快发现并修复问题。”
  • Sensors 显示，同一时间窗口内 Login 共 332,904 PV / 245,068 UV，其中 error_code=30100225 为 188 PV / 107 UV。按事件量计算失败占比 0.056%，按去重用户计算占比 0.044%。
  • 错误并非只出现在反馈对应的 iOS 旧版本：Android 产生 166 PV，iOS 14 PV，HarmonyOS 8 PV；按版本拆分，8.4.1.6 的 Android 端最多，为 142 PV / 72 UV。
  • 明确标注“点击第三方登录”的失败为 173 PV，其中 Android 157、HarmonyOS 8、iOS 8；另有少量 30100225 落在用户名密码登录、切换账号或场景字段为空的事件上，说明错误码仍可能通过公共登录失败分支回流。
  • 9 时至 16 时各小时均有发生，16 时达到本次窗口峰值 40 PV / 18 UV，不是单个时刻的瞬时抖动。
  • 严重度评分：80 / 100。反馈量 10（1 条显式反馈，但 Sensors 有 107 名受影响用户）、共性广度 30（3 个平台、多版本、多地区）、业务关键度 40（登录阻断全部后续业务链路）。
  • 去重判定：2026-10-18 第 240 期已分析微信授权码重复提交，任务 T-20261018-090804-7ee8 仍为 P1 / captured。本期不是同一条旧反馈复述，而是新增跨端用户级证据和新的单次失败样本，因此更新既有任务，不重复创单。

Sensors 证据

  • 同口径 9 时至 16 时历史对比：10 月 17 日至 23 日的 30100225 分别为 273、291、189、172、210、188、188 PV，影响用户分别为 162、151、101、102、129、116、107 UV。
  • 今日事件量与此前两日持平，没有出现突发尖峰，但每天稳定有百名量级用户遇到授权失败，符合长期未闭环的服务端校验或客户端恢复缺陷，而不是偶发误操作。
  • 反馈对应的 iOS 8.1.204 今日有 5 PV / 5 UV；iOS 最新构建 8.4.106 另有 9 PV / 9 UV，说明该错误仍存在于多代版本。
  • 当前没有可直接关联反馈 clientId 与 Sensors distinct_id 的映射，因此不能把 259063 精确计入上述 107 名用户；用户反馈与大盘事件只能作为同错误码、同窗口的交叉证据。

Logan 与附件

  • 反馈 259063 上传 OBS 日志 ac7ff94f...zip，Log0.txt 共 7,448 行，日志时间覆盖 13:10:41 至 13:25:12。
  • Log0.txt:7435-7440：请求参数包含 grant_type=third_party_code、third_party=wechat，且 third_party_code=011XCa2009wBrT1s91300CTSnj0XCa2m 非空。
  • 同一请求立即返回 {"code":30100225,"success":false,"msg":"授权码校验失败","rid":"c92f00cbafbd463582d02a33376ad549"}。
  • Log0.txt:7441-7442：客户端记录“第三方登录接口执行失败”，随后直接展示“登录失败(30100225)”，没有执行重新授权或切换登录方式的自动恢复。
  • 本样本只提交了一次授权码，不能据此认定本期是重复提交；但可以确认失败发生在服务端校验阶段，并非空 code、断网或客户端未发出请求。

代码定位

  • 涉及模块：Seetong-App-iOS/Seetong5.0_ios/Seetong_tps/Classes/Login。
  • STLoginViewController.m:1125-1130：微信成功回调直接使用 response.code 发起登录，没有校验 response.state、code 非空、重复回跳或请求代次。
  • STLoginViewController.m:1438-1462：每次微信授权使用固定字符串 state = @"xxx"，无法区分旧回调、重复回调和当前授权请求。
  • STLoginViewController.m:777-850：授权码经 kEmptyStr(authCode) 进入请求体，提交前没有“一次性消费”状态；只有空值会被转成空串。
  • STLoginViewController.m:854-907：失败分支只对账号冻结、验证码不存在和安全验证做专门处理，30100225 落入通用错误提示；没有清空授权态、重新拉起微信或引导其他登录方式。
  • STResponseModel.h:105-113：30100225 明确定义为 STRequestLoginVerfityFail，即“授权码校验失败”，但页面层未使用该枚举建立专用恢复路径。
  • 提交 1678489cbd005f32bf54a1c6c170b092bd765a29 曾修复“非授权回调传空 code”的问题，但当前逻辑仍未解决旧 code、已消费 code、微信侧拒绝和服务端校验失败后的重新授权闭环。

根因结论

  • 置信度：现象 🟢 强；请求确实到达服务端并被拒绝 🟢 强；单一客户端根因 🟡 中。
  • 一句话根因：微信回调缺少随机一次性 state、单飞门禁和授权码消费标记，30100225 又落入通用失败分支；服务端拒绝后客户端保留旧授权态，用户只能看到错误码，无法自动获得新的有效授权。
  • 关键证据链：259063 明确反馈登录失败 → Logan 证明微信 code 非空 → 服务端以 30100225 拒绝 → 页面直接展示通用错误 → Sensors 在 8 小时内记录 188 次、107 名受影响用户，且跨 Android、iOS、HarmonyOS 持续存在。
  • 明确不下的结论：现有服务端响应只说明“授权码校验失败”，没有区分 code 过期、已被消费、微信应用配置不匹配或微信侧风控。不能把 107 名用户全部归因于客户端重复提交。

建议下一步

  • 分配给：位冬负责 iOS 微信授权与登录恢复，欧阳荣复核登录状态机和埋点口径；Android、HarmonyOS 登录负责人共同核对各自第三方登录 code 的消费与重试逻辑。
  • 先在服务端按 rid=c92f00cbafbd463582d02a33376ad549 查询微信授权码换取用户信息的原始结果，确认本次是过期、已消费、应用配置不符还是微信侧拒绝。
  • 每次授权生成随机一次性 state；在回调入口校验 state、errCode、code 非空和请求代次，并对同一回调做幂等与单飞去重。
  • 授权码一经提交即从当前会话与恢复缓存中消费。遇到 30100225 时禁止复用旧 code，应清理授权态、明确提示“授权已失效”，提供“重新微信授权”和“其他登录方式”两个出口。
  • 补齐 login_platform + error_code + rid + auth_attempt_id + code_age_ms + callback_count + state_match 埋点；服务端与三端客户端使用同一 rid 串联，避免只能看到笼统错误码。
  • 回归微信热启动回跳、冷启动 Universal Link、重复回调、同一 code 双击提交、进程重启恢复、用户取消、code 过期、code 已消费、微信应用配置异常九类场景。
  • 任务账本：沿用 T-20261018-090804-7ee8，保持 P1 / captured，等待服务端 rid 回查和跨端修复证据。

本期扫描全量

分类与处置反馈数反馈 ID 或说明
🟠 跨端 30100225 登录失败，进入问题 11259063
🔁 HarmonyOS 1.1.2.3 回放、离线与连接同域问题，24 小时内已分析6259089、259094、259098、259104、259108、259112；计入任务 T-20260926-170258-2226 和 T-20260926-115214-fdf9
🟡 HarmonyOS 报警消息不更新，同一 MIA-AL00 用户重复提交2259062、259090
🟡 跨版本单点视频、设备连接、云台、添加设备或登录异常，暂未形成新的跨用户根因9259037、259039、259041、259045、259047、259051、259052、259054、259066
🟢 设置、供应商与硬件问题咨询3259035、259068、259101
🟤 测试、需求建议、乱码或信息不足10259016、259046、259050、259075、259076、259077、259097、259099、259103、259106
已折叠 1 条普遍性网络问题（含 -102/-101/-1002 与中/英/俄/法/西/葡/土/阿/日多语言网络提示模板，如 Проверьте телефонную сеть、Please check your mobile network）；全量明细见同名 Markdown 知识库。
反馈接口返回 total=99 / fetched=99 / complete=true / pages=2。上表按主问题唯一归类，合计 99 条。259098 与 259099 为同一用户连续提交，按 1 名用户观察；259062 与 259090 同为 HUAWEI MIA-AL00、山东，暂按同一用户重复反馈处理。HarmonyOS 回放与离线簇已在第 249 期进入雷达，本期仅记录持续信号，不重复计分。

心愿单亮点

心愿单 ID平台与版本诉求价值判断
5466Android / 8.4.1.6批量分享摄像头时支持搜索⭐⭐ 工程商设备多时能降低查找成本，可优先复用现有设备搜索能力
5463Android / 8.4.1.6区分人物、动物和物体检测⭐⭐⭐ 与 AI 告警准确性直接相关，需明确模型能力、误报口径和推送策略
5462Android / 8.3.14.2摄像头经常离线，希望减少掉线⭐⭐⭐ 属于设备在线率问题，需拆设备、固件、网络与服务端心跳链路
5461Android / 8.4.1.6夜间车辆检测漏报率高⭐⭐⭐ 用户给出“10 次约 8 次未检出”的量化感受，应结合设备端算法日志复核
5459Android / 8.4.1.6硬盘异常时支持远程格式化⭐⭐⭐ 有运维价值，但必须增加二次确认、权限校验和误操作保护

数据源状态

  • 反馈平台：✅ 正常。total=99 / fetched=99 / complete=true / pages=2，逐条分类覆盖全部 99 条。
  • 心愿单：✅ 正常。total=12 / fetched=12 / complete=true。
  • Sensors：✅ 主查询成功。完成 Login × 30100225 的当前窗口、平台、版本、登录方式和小时分布查询，并核对 DeviceVideoPlayback 与 SDVideoDownloadEvent。
  • Logan：⚠️ 部分可用。259063 的 OBS 日志完整证明非空微信 code 与服务端拒绝响应；其他大多数单点反馈没有同时提供可覆盖故障时刻的日志。
  • 友盟：⏭️ 未调用。本期核心问题不是崩溃或 ANR。
  • TAPD：⏭️ 未调用。当前有明确错误码、用户日志和跨端神策证据，先用任务账本推进服务端 rid 回查。
  • 代码仓：✅ Seetong-App-iOS 已定位登录回调、授权参数和失败恢复代码；Android 与 HarmonyOS 当前工作区有未提交的业务改动，本期只读查阅，未修改代码。
  • 任务账本：本期更新 T-20261018-090804-7ee8；HarmonyOS 回放与离线持续信号沿用既有任务。
  • 待补证：需服务端按 rid 回查微信 code 的校验结果；需 Android 与 HarmonyOS 各补一份 30100225 的同类 Logan，确认三端是否共用同一服务端校验链路。

下一期 = 第251期 = 2026-10-24-H09.md（明天早上 09:00；窗口 今日 17:01～明日 09:00）

🗂️历史期次

查看全部历史期次（近 90 天）→

由 OpenClaw 统一报告渲染器生成 · 最新更新时间：2026-10-23 17:11 · 数据以同名 Markdown 原始报告为准