有一段时间，国内用户点开一段录音要等三十到六十秒才出声。
我们在本地怎么测都很快。猜了好几轮，都猜错了。
转折点是一张截图
一位客户把浏览器的网络面板截了个图发过来。
那张图里能直接读出三件事：
- 有两条请求走的是本机磁盘缓存
- 播放器那条请求抢走了一部分数据
- 整个文件三点几兆，跑了一分半
第三条一除，答案就出来了：这位客户到我们这里，大概每秒三十几千字节。
有了这个数字，之前的争论全部作废
在此之前我们讨论的是「代码哪里写得不好」。
有了这个数字，问题变成了另一个：在每秒三十几千字节的这条线上，代码能做什么？
答案很不一样：
- 我们之前做过的一个优化，解决的是服务器内存，和链路长度无关——所以它对这个问题一点用没有
- 真正能做的只有：让用户更早听到第一声、让等待有反馈、别让请求互相抢
定下来的四条
顺着这个数字，四条改动全是「在这条线上省」：
① 后台下载和播放器用不同的地址。 同一个地址的并发请求浏览器会排队——原来后台下载得等播放器那段传完才开始，在慢网上就是「过了一分钟才开始缓存」。
② 播放优先。 用户一点播放，就掐断后台下载让路；他一停，从断点续上。
③ 失败不许静默。 重试三次再显示失败。而且「连续三十秒收不到字节」也算断——因为浏览器在断网时，进行中的下载不报错，只是挂着，等报错永远等不到。
④ 状态常驻。 缓存中、已完成、失败，这些状态不再几秒钟就消失。
第四条是被用户教会的
第四条最初不在名单里。是客户又反馈了一次：「怎么感觉没缓存啊」。
原因很朴素：第二次打开的时候，文件已经在磁盘缓存里，零点一秒就完成了。 状态闪一下就没了，用户根本没看见——于是他以为没缓存。
一个快到看不见的成功，在用户那里等于没发生。
这件事的一般形式
一个真实用户的现场读数，能一次性排除掉你猜的九成可能。
而我们本来早就可以要这张截图。之所以没要，是因为觉得「让客户去开开发者面板太麻烦了」。
实际上他两分钟就发过来了。
怎么问
关键是别问感受，问读数。
- ❌ 「你那边大概多慢？」——得到的是「挺慢的」
- ✅ 「方便的话，按 F12 打开网络那一栏，刷新一下，把列表截个图发我」——得到的是三个可以直接算的数字
做研究的对这个区别应该很熟：问「你觉得这个产品怎么样」和问「你上一次用它是什么时候、当时在做什么」，得到的完全不是同一种信息。
排查线上问题，用的是同一套提问纪律。