先描述症状
登录失败、连接失败、连接后页面打不开和下载中断属于不同问题。把发生步骤写清楚，比只说“不能用”更容易定位。
记录第一次出现的时间，以及是否能够连续复现。
固定现场条件
选择一台设备、一个网络和一个目标页面进行复核。不要同时更换客户端、网络、浏览器和账号。
当多个条件一起变化时，即使恢复也很难知道原因。
保存提示原文
系统和客户端提示里的词语通常对应不同环节。可以记录文字或截图，但应遮住个人账号、通知和其他隐私。
不要提交密码、验证码、私钥或付款资料。
比较另一种网络
在条件允许时，用移动网络或另一 Wi-Fi 对照。若只有一种接入方式异常，排查范围会更清楚。
切换后等待网络状态稳定，再执行相同任务。
查看公开背景
多个服务同时异常时，可以参考公开状态页或网络异常信息，但它们只能提供背景，不能替单台设备下结论。
本地时间与公开事件时间也要一致，避免把不同阶段混在一起。
提交有效反馈
最终反馈包含设备、系统、客户端版本、网络类型、发生时间、目标页面、提示原文和已做过的简单对照即可。
这份记录既保护隐私，也方便后续复盘和持续改进。
建立问题排查判断基线
一份有效日志可以很短：设备与系统、客户端版本、网络类型、发生时间、目标页面、提示原文，以及是否在另一种网络下复现。它不应该包含密码、验证码、私钥、身份证件或付款信息。截图前先遮住通知栏和个人账号，既能保护隐私，也不会影响技术判断。记录的顺序同样重要：在更换网络之前是否已经失败，重新打开应用之后是否恢复，只有图片慢还是所有页面都打不开。把这些事实按发生时间写下来，通常就能判断下一步该检查设备、接入网络还是目标服务，避免在多个设置之间盲目来回修改。
日志完成后可以按结果分流。如果另一种网络能够稳定打开同一页面，接入环境值得优先检查；如果所有网络都只在同一应用失败，客户端版本、权限与会话状态更相关；如果多个设备同时对同一目标失败，则可以参考目标服务与公开网络背景。每个判断都应写成“目前更接近”，而不是在证据不足时下最终结论。问题恢复后，也记录发生了什么变化，例如等待一段时间、重新打开应用或切换网络。这样的复盘能避免以后重复尝试无效操作。日志的价值不在于字段很多，而在于条件一致、顺序清楚，并且没有混入不必要的敏感资料。连续几天出现同类问题时，可以把每日记录并排比较，观察是否集中在固定时段或同一网络；若现象没有稳定规律，就保留为待观察状态，不急着修改更多设置。一次有效反馈还应说明哪些简单对照已经做过，避免支持人员让用户重复同样步骤。问题消失也值得记录，恢复时间能帮助区分短暂波动与持续故障，并为下一次复核保留参照。