I4.03.1polling lag and waste设计
轮询简单但存在延迟与浪费
别名: 轮询 · polling · 定时拉取 · pull interval
概念解释
轮询（polling）按固定或退避的间隔去问服务器「有没有新的」。实现上几乎只需定时器和一次请求，不依赖长连接。代价写在时间账上：新事实平均要等半个间隔才被看见，多数询问空手而归。它适合变化慢、丢几秒无所谓、连接环境不稳定的读。
机制
客户端握着钟，服务端是被动的。事件在两次询问之间发生，发现它的期望延迟是间隔的一半；最坏是刚问完就发生，要再等一整格。为了把延迟压下去只能加密，空请求的比例随之上升——变化没有变密，问的人变勤了。这就是浪费：带宽、电量、服务端 QPS 都花在确认「还是旧的」上。
退避（出错或无变化时拉长间隔）能把浪费压下来，但延迟会在安静期变差，人一旦在安静期末尾动手，会撞上「怎么还是旧的」。多开几个标签各轮询一份，浪费按标签数倍增，服务端看到的是同一用户的重复心跳。
边界
内容几乎每秒都在变（行情、对战状态），轮询要跟得上就会变成近乎常开的短间隔请求，简单性还在，浪费已经接近一条笨拙的长连接，该换通道。写后立刻要读到自己的写入，轮询的半间隔延迟会让人以为没写上，需要在本地先承认，而不是把间隔收到零。后台标签、锁屏、省电模式会把定时器推迟或合并，墙上的间隔不再是实际间隔，延迟比设计值更差。服务端若按「每次询问都做全量计算」，浪费从空响应变成空计算，间隔再长也贵。
怎么落地
- 变化以分钟计、过时几秒可接受的列表、角标、非对话状态，用轮询；不要用它做「对方正在输入」或对战帧。
- 公布可见延迟预算：间隔的一半是用户平均等到的新鲜度，不要把间隔本身当成新鲜度。
- 无变化时拉长间隔，有交互或回到前台时立刻问一次；同一账号多标签要合并成一条轮询。
- 验证：在两次询问正中插入一条服务端更新，界面应在下一格出现，而不是当时。把间隔加密到接近连续请求，看空响应占比——若绝大多数是「无变化」，浪费已经大于简单性。