先固定一个轻任务和一个重任务
文字页面一直正常，图片、更新或较重任务偶尔波动时，单次测速很难回答原因。测速是某个时刻、某条路径和某种传输方式的切片；轻任务与重任务对连接建立、响应等待和传输量的敏感程度不同。先选两个能重复的公开任务，记录开始时间、首次出现内容、是否完整以及过程中有没有中断。
设备、客户端、账号、配置与接入网络先保持不变。第一轮观察五到十分钟，不追求最高值，只看现象能否重复。轻任务和重任务同时停住，才更像共同层的问题；轻任务稳定、重任务变慢，应先描述吞吐或路径差异，不直接写成节点故障。
一次较快不证明长期稳定，一次较慢也不能定位到设备、节点或服务端。对照要回答“改变哪个条件后，现象是否跟着移动”。
DNS成功只说明名称解析完成
DNS把域名经过解析器和权威服务器转换成网络地址。解析成功，说明名称查找完成，并不代表登录、配置、客户端内部处理或端到端任务都正常。浏览器的Resource Timing还能把DNS、连接建立、请求、响应和传输分成阶段，这提示我们不要把所有等待都叫作网络慢。
不过浏览器计时不能测量专有客户端里的每个步骤。普通用户也不需要为每次波动抓取复杂数据。记录“页面是否开始响应、内容是否完整、客户端状态是否改变”已经足够。若名称解析失败，多个页面可能同时受影响；若页面稳定而应用任务异常，应把浏览器与客户端分开写。
网络延迟由传播、传输、处理和排队等环节共同形成，一个延迟数字不能指出具体哪一段变化。结论必须保留这种边界。
第二轮只改变时间或接入网络中的一项
第一轮在家庭Wi‑Fi完成后，第二轮可以只换可信手机热点，任务和时长相同；或者保持网络不变，换到另一个时间段。不要同时换设备、客户端和配置。若现象只随接入网络改变，说明接入环境值得继续检查，但仍可能涉及DNS、路由、过滤或短时拥塞，不能直接归责某个服务。
热点用于短时对照，不是永久解决方案。对照后回到原网络复测，确认差异能否再次出现。若两个网络的轻任务都稳定、重任务都波动，应记录任务差异；若所有任务在特定时间同时变化，时间窗口比单个速度值更有意义。
把结果写成两行即可：条件、任务、时长、结果。不要只保存一张最高速度截图，因为它缺少任务和观察过程。
手机还要分开前台与后台
移动端的省电、锁屏和后台活动策略会改变应用行为。Android允许用户在系统设置中查看并更改权限，但菜单位置因版本和厂商而异。前台稳定、锁屏后断开时，先记录为后台差异，不要把它混入Wi‑Fi与热点对照。
第三轮可以保持家庭Wi‑Fi与任务不变，只增加锁屏；第四轮再查看与应用直接相关的后台设置。每轮结束都恢复不相关的改变。权限越多不等于网络越快，关闭全局系统保护也不是诊断办法。
桌面端则可比较正常前台和休眠恢复。不同平台的对照条件不必相同，但每一轮都应清楚写出唯一改变的条件。
用有边界的语言写结论
好的结论是：“同一手机和家庭Wi‑Fi下，文字任务十分钟稳定，图片任务第六分钟出现一次延迟；热点对照未复现；尚未覆盖晚间和锁屏。”它包含条件、任务、时长、差异与未知范围。差的结论是“线路不稳定”或“某节点拥堵”，因为现有记录没有足够证据支持。
若只有一轮样本，就明确写样本有限。若变化不能重复，也保留这一点，不为了得到整齐答案反复尝试。观察记录用于缩小范围，不发布实时测速、线路排名或节点承诺。
下次出现类似现象时，从同一组轻重任务开始，与旧记录比较。只要设备、系统、网络或客户端发生变化，就把它写入新一轮条件。可比较性来自清楚边界，不来自更多漂亮数字。
资料与结论边界
网络观察部分借用MDN资源计时以及Cloudflare对DNS与延迟阶段的说明。浏览器指标无法覆盖专有客户端内部，也不能从一个数值定位具体节点或发布实时线路结论。