01延迟与带宽关注不同问题
延迟描述等待传递与返回所需要的时间，带宽则关系到持续传输的数据量。高带宽不保证每次交互都迅速，低延迟也不代表能够高速下载大文件。应用体验还受到服务处理、资源依赖和设备负载影响。描述故障时，应分清是每次操作都固定等待、偶尔突然卡顿，还是持续传输不足，避免只用“网速差”覆盖多个不同现象。
02平均值之外也要看波动
同一目标在不同时刻的等待可能不同，短时拥塞和无线竞争都可能带来变化。单个平均数会掩盖偶尔出现的长等待，因此应结合具体操作观察多次结果。记录发生时间、接入方式与背景任务，而不是只保存一个最好看的数字。测试次数与间隔也会影响你看到的情况，不宜根据极少量结果推断长期质量，更不应把不同目标直接放在一起排名。
03丢包测量需要结合协议理解
某种探测没有收到回复，可能与目标的响应策略、限速或路径有关，不能直接认定所有应用都丢失了相同比例的数据。不同通信方式对重传、超时和容错的处理也不同，应以实际业务表现和相关日志作为补充。不要看到某个中间设备不回复就立即判断它发生故障。关注目标应用是否能完成请求，以及异常是否能在一致条件下重复观察。
04应用响应包含更多阶段
一个请求从发起到展示内容，可能经历解析、连接、加密协商、服务处理和下载。即使基础往返时间变化不大，服务繁忙或资源依赖也可能让页面等待变长。需要结合当前可见的阶段信息找原因，而不是只看单一延迟值。若仅某个目标异常，先比较其他熟悉目标；若多个目标同时变化，再考虑公共接入或设备环境，避免结论超出观察范围。
05网络切换与已有连接要分开看
从无线切换到移动网络或插入有线接口时，旧连接可能需要重建，短时重试会影响体验。先等待接入稳定，再使用新的请求比较，并保持目标和操作一致。信号波动时不要同时调整多个配置，否则很难确定改动效果。对于依赖实时交互的应用，也要注意后台传输是否抢占本地接入资源，先减少可控因素再进行测试。
06形成有证据的排查记录
保留目标、平台、网络、时间与可复现步骤，并标记每次调整和恢复结果。若无法稳定复现，先收集发生条件，避免凭一次结果修改整个配置。问题集中在加载速度时可阅读 传输与本地环境指南；问题发生在切换后可看 网络切换知识。请求失败则应回到 连接状态检查，明确它在哪个环节停止。