IMAP IDLE 是什么
IDLE 让服务器主动把变化推给客户端，客户端不必反复询问。客户端发出 IDLE 命令后，服务器回一条继续应答，连接进入等待状态；一旦有新邮件到达或标志发生变化，服务器立刻把变化推过来。用户感受到的就是「邮件秒到」。规范建议服务器在这个状态下把连接稳定保持住，客户端结束等待时发送结束命令即可回到正常命令状态。
基本信息
| 规范 | RFC 2177 |
|---|---|
| 交互流程 | 客户端发 IDLE，服务器回继续应答后进入推送状态 |
| 保活 | 服务器可用注释行维持连接，RFC 要求至少维持 30 分钟 |
| 结束方式 | 客户端发送结束命令回到命令态 |
| 客户端要求 | 被断开后能自动重连并重新进入等待状态 |
| 影响体验的环节 | 手机省电策略、防火墙空闲超时 |
IDLE 交互过程
IDLE 交互过程
a1 IDLE
+ idling # 服务器确认进入等待状态
* 23 EXISTS # 推送：邮件数量变化
* 1 FETCH (FLAGS (\Seen)) # 推送：标志变化
DONE # 客户端结束等待
a1 OK IDLE terminated常见推送延迟来源
| 现象 | 可能原因 | 验证方式 |
|---|---|---|
| 长期无推送 | 连接被中间设备静默断开 | 抓包看连接是否还在，观察是否有重连 |
| 延迟数分钟 | 客户端等待状态维持时间过短 | 查看客户端重连间隔设置 |
| 手机端不同步 | 系统省电策略限制了后台连接 | 对比同一账号在桌面端的表现 |
| 偶发漏推 | 重连期间的变化未重新同步 | 重连后重新查询一次状态 |
典型使用场景
- 排查「必须手动刷新才收到新邮件」：多为长连接被断后未重连
- 移动端推送优化：结合系统推送通道减少长连接被系统回收的影响
- 客户端开发：实现断线重连并在重连后补一次全量状态核对
- 企业网络策略评估：确认防火墙的空闲超时时间长于客户端的保活间隔
- 容量规划：长连接数量随在线用户增长，需要单独评估服务端连接承载
排查推送延迟时，先分清是「服务器没推」还是「连接早已不在」：在服务端看该账号的长连接是否仍然存在，在客户端看有没有重连日志，比反复重启客户端有效得多。中间设备的空闲超时与客户端的保活间隔需要互相匹配，两边都设得保守才能稳定。