在处理邮件系统对接时，Ruby的Net::IMAP库是常用的标准工具。当我们需要获取邮箱中大量邮件的大小而并不下载正文时，如果采用传统的逐封fetch方式，会产生极高的网络往返开销。通过fetch_rfc822_size方法配合UID（唯一标识符）进行批量查询，可以显著降低延迟并减少连接占用。这种方式特别适合做邮件归档扫描、容量预警以及垃圾邮件体积分析等后台任务。
一、为什么直接用SEQfetch邮件大小很慢
IMAP协议里每封邮件在某一会话中有一个序号（sequence number），它随邮件删减而变化。很多初学者写脚本会循环调用fetch(i, "RFC822.SIZE")，其中i从1递增到邮件总数。这种做法的问题在于：每次fetch都是一次独立请求与响应，假设邮箱有五千封邮件，客户端就要发送五千次命令并等待服务端确认。
更麻烦的是，如果中途有邮件被其他客户端删除，序号会平移，导致你原本要取的某封邮件对应到错误实体，还得额外做一致性校验。下面的代码展示了典型的低效写法，它在网络延迟为30ms的环境下，仅获取大小就要消耗两分多钟。
require 'net/imap'
imap = Net::IMAP.new('ipipp.com', 993, true)
imap.login('user', 'pass')
imap.select('INBOX')
total = imap.respond_to?(:uid_search) ? imap.search(['ALL']).length : imap.search(['ALL']).length
# 低效：用序号逐封取大小
(1..total).each do |seq|
data = imap.fetch(seq, 'RFC822.SIZE')
puts data[0].attr['RFC822.SIZE']
end
imap.logout
imap.disconnect
二、fetch_rfc822_size与UID的基础用法
Net::IMAP的fetch_rfc822_size是封装好的便捷方法，它底层等价于fetch(uid_set, 'RFC822.SIZE')但语义更清晰。关键不在于方法名，而在于第一个参数应当传UID集合而不是序号。UID在邮箱生命周期内稳定，且IMAP允许用逗号或冒号表达区间，例如"1:100,200,300"一次性发给服务端。
使用uid_fetch系列方法时，要先通过uid_search获取目标UID列表，再切片批量请求。这样网络往返从N次降到几十分之一。以下示例展示如何用UID区间拉取大小，并顺便打印出来做核对。
require 'net/imap'
imap = Net::IMAP.new('ipipp.com', 993, true)
imap.login('user', 'pass')
imap.select('INBOX')
uids = imap.uid_search(['ALL'])
# 每五百个UID为一批
uids.each_slice(500) do |batch|
uid_set = batch.join(',')
# 使用fetch_rfc822_size配合UID
result = imap.fetch_rfc822_size(uid_set)
result.each do |item|
uid = item.attr['UID']
size = item.attr['RFC822.SIZE']
puts "uid=#{uid} size=#{size}"
end
end
imap.logout
imap.disconnect
三、性能对比与底层原理
从协议角度看，IMAP的FETCH命令支持在一个请求里声明多个UID，服务端一次性返回各邮件的RFC822.SIZE属性。由于不拉取正文（BODY或RFC822），响应体极小，主要成本集中在命令往返与解析。下表列出两种方案在五千封邮件下的差异：
| 方案 | 请求次数 | 耗时（30ms延迟） | 内存峰值 |
|---|---|---|---|
| 序号逐封fetch | 5000 | 约150秒 | 低 |
| UID批量fetch_rfc822_size | 10 | 约3秒 | 中 |
可以看出，UID批量方式将请求次数压缩到原来的千分之二，耗时随之后非线性下降。内存方面因为要暂存一批结果，会比逐封处理略高，但可通过调小切片来控制。底层上，服务端对UID索引的查找比按序号从头遍历更友好，尤其当邮箱启用了UIDVALIDITY缓存时。
四、连接保活与超时避坑
即便用了UID批量，若邮件量达到十万级，单批处理时间仍可能触发服务端空闲断开。Net::IMAP默认无显式超时，但网络中间设备常会切断长连接。我们可以在每批之间发noop命令保活，或者捕获异常后重连并续传UID游标。
下面的代码演示了带保活与断点续传逻辑的完整模板，它记录已处理的最大UID，出错时从下一个UID继续，避免重复劳动。同时用each_slice(1000)平衡批大小与内存。
require 'net/imap'
def safe_connect
imap = Net::IMAP.new('ipipp.com', 993, true)
imap.login('user', 'pass')
imap.select('INBOX')
imap
end
imap = safe_connect
uids = imap.uid_search(['ALL'])
max_done = 0
uids.each_slice(1000) do |batch|
begin
set = batch.select { |u| u > max_done }.join(',')
next if set.empty?
imap.fetch_rfc822_size(set).each do |it|
max_done = it.attr['UID'] if it.attr['UID'] > max_done
end
imap.noop # 保活
rescue Errno::ECONNRESET, Net::IMAP::Error => e
puts "重连：#{e.message}"
imap = safe_connect
retry
end
end
imap.logout rescue nil
imap.disconnect rescue nil
五、总结与实践建议
将fetch_rfc822_size与UID结合，本质是把随机小请求聚合成有序批量请求，并借UID的稳定性规避序号漂移。实际项目中，建议先把UID全量搜出存入本地队列，再用多线程消费不同UID段，但注意同一IMAP连接非线程安全，应每线程独立连接。
如果只需估算邮箱占用，也可改用uid_search配合'LARGER'条件先筛大邮件，再针对性取大小。总的来说，掌握UID视角与批量FETCH，是Ruby邮件脚本从玩具走向生产的关键一步。