DIAGNOSTICS
后台数据正常，直播仍然卡顿：还需要查哪些记录？
后台未见异常而直播仍卡顿时，如何对齐发生时间、监测范围和客户端日志，继续核对上行丢包、内网中断及软件线索。
主播反馈卡顿，维护后台却显示正常，并不代表其中一方判断错误。先确认后台查看的是什么位置、哪段时间，以及客户端实际发生了什么，再把双方的记录对齐。
一次跨越数日的维护记录中，最初查看后台未见明显异常，退出重登后暂时恢复；几天后又出现卡顿，随后技术人员分别报告上行丢包和内网闪断线索。记录没有提供最终维修与验收结果，适合讨论排查方法，不能写成已经彻底修复的案例。
一、先区分“没有看到异常”和“所有环节正常”
后台某个面板正常，只能说明查看范围内未发现异常。需要进一步确认监测位置是否覆盖主播电脑到网络设备的连接，以及数据时间段是否与卡顿发生时一致。
如果只看事后状态，或者面板展示的是较长时间的汇总，就还需要当时的日志才能判断。是否存在短时异常被汇总数据掩盖，应核对采样和日志记录方式，不能直接假定。
二、这份记录实际确认了什么？
| 时间 | 原记录中的观察 | 可以保留的结论 |
|---|---|---|
| 10 月 3 日 | 主播反馈卡顿；技术人员查看后台未见明显异常；退出重登后暂时恢复 | 有体验与后台观察不一致的情况，重登后的恢复尚不能解释原因 |
| 10 月 6—7 日 | 再次出现卡顿，包含 PK 场景 | 问题有复发，需要继续追踪 |
| 10 月 8 日 | 技术人员报告“上行有超宽丢包” | 上行容量和丢包成为需要核对的线索 |
| 10 月 9 日 | 技术人员报告此前某时刻发生内网闪断 | 应对照该时刻检查本地连接；记录没有定位到具体设备 |
上行丢包与内网闪断出现在不同时间。缺少原始指标和日志时，不能将它们拼成同一个已被证明的根因，也不能据此排除公网链路或软件问题。
补充记录：连接提示与诊断结论要分别保留
另一份维护记录中，9 月 30 日技术人员反馈此前出现内网丢包、随后恢复，并表示将继续跟进半小时。原记录没有提供完成半小时观察的结果，因此不能改写成“已跟播半小时确认稳定”。
10 月 7 日，该份记录中又出现卡顿和黑屏，技术人员报告海外运营商服务器故障，随后通知网络已可用。这是另一次事件，不能用它解释此前所有卡顿，也不能把当时预估的恢复时长写成承诺。
两张提示图分别呈现客户端当时的报错，没有显示内网丢包或运营商故障的完整诊断数据。它们只作为现象配图，不与某项原因强行对应；这两次事件也不与前述 10 月 3—9 日的时间线拼成同一故障。
三、主播先记录这些信息
卡顿时先记下具体时间和时区，区分本端预览卡、观众看到卡、对方 PK 画面卡，还是只有声音异常。同步保存客户端提示和码率状态，记录当时是否切场景、进入 PK 或增加了其他联网设备。
如果需要退出重登以恢复直播，先在条件允许时保存提示和日志。记录操作时间及恢复结果；短暂恢复只说明该操作后症状消失，不能反推原因已经确定。
对外提交截图前，遮挡昵称、头像、人脸、群信息、联系方式和设备地址。技术人员如需原始日志定位，应通过双方约定的安全渠道处理。
四、技术人员怎样对照排查？
| 线索 | 需要核对的记录 | 下一步 |
|---|---|---|
| 上行占用或丢包 | 同时段的流量、实际推流码率、其他上传任务及限速配置 | 保持场景不变，一次减少一个上传任务或调整一项参数，再对比 |
| 本地连接中断 | 对应时间的网口状态、设备重启和链路日志 | 按设备逐段检查供电与连接，使用匹配的线缆做对照 |
| 软件卡顿或编码异常 | 客户端日志、编码状态、CPU/GPU 等负载 | 退回最小软件组合，逐项恢复组件 |
| 其他设备同时异常 | 各设备时间点、共用网络路径和服务状态 | 交由维护人员核对共用环节及上游事件 |
每次调整都记录改了什么、何时改、测试场景和结果。如果没有改善，回到前一项配置，避免连续改动后失去对照。
五、恢复后还缺哪一步？
回到此前容易卡顿的场景复测，覆盖类似负载和运行时长；同时观察主播端、观众端及相关日志。若再次发生，把新的时间点与此前记录并列比较，而不是沿用上一次的判断。
这份记录尚缺具体故障设备、维修动作和复测结果。因此，文章结论应停留在“如何继续查”，不写成“已经找到隐形闪断的唯一原因”。
和测速排障文章有什么区别？
测速很好但直播仍卡顿的排查讨论测速结果与直播体验的差别。本篇重点是维护后台与客户端记录怎样对齐，两篇互相补充，无需重复展开测速方法。
