当使用 go-imap 库执行 `uidsearch` 时，若服务端返回的匹配邮件 id 列表过长（如数万个 uid），会触发 `"line too long"` 错误，因其超出默认 64kb 行长度限制；后续 `searchresults()` 调用还可能因解析失败导致 panic。
在 Go 中使用 mxk/go-imap 进行邮箱操作时，UIDSearch 是获取未读邮件 UID 的常用方式。但当收件箱中存在大量未读邮件（例如上万封），IMAP 服务器通常会在单行中以空格分隔形式返回所有匹配 UID（如 * SEARCH 45081 45082 ... 45249），该响应极易突破 go-imap 默认的 65,536 字节（64KB）行缓冲上限 —— 这正是 imap: line too long 错误的根本原因。
更严重的是，一旦底层 bufio.Reader 因超长行截断或丢弃数据，cmd.Data[0].SearchResults() 将返回空切片或不完整结果，进而导致 set.AddNum(...) 调用时传入空 slice，最终在 UIDFetch 阶段因空序列集引发 index out of range panic。
✅ 正确应对策略
1. 避免单次全量搜索：分页式范围查询
不要使用 "1:* UNSEEN" 这类宽泛条件。改用时间范围或 UID 区间分批查询，显著压缩每条 SEARCH 响应长度：
// 示例：按日期范围分页（需服务器支持 DATE 或 SINCE）
cmd := ReportOK(c.UIDSearch(`SINCE "01-Jan-2024" UNSEEN`))
// 或按 UID 区间分段（推荐，兼容性更好）
const batchSize = 1000
var allUIDs []uint32
for start := uint32(1); ; start += batchSize {
end := start + batchSize - 1
// 构造区间搜索："(UID 1:1000 UNSEEN)"
query := fmt.Sprintf("UID %d:%d UNSEEN", start, end)
cmd := ReportOK(c.UIDSearch(query))
if len(cmd.Data) == 0 || len(cmd.Data[0].SearchResults()) == 0 {
break // 无新结果，退出
}
allUIDs = append(allUIDs, cmd.Data[0].SearchResults()...)
}2. （谨慎）增大 BufferSize（仅临时调试用）
虽然可全局修改 imap.BufferSize，但不推荐生产环境使用——它违反 RFC 2683 建议的「客户端应将物理行限制在 ~1000 字节内」原则，且无法解决协议层设计缺陷：
// ⚠️ 仅用于调试，勿用于线上！ imap.BufferSize = 1024 * 1024 // 1MB
3. 健壮的错误处理与空结果防御
始终校验 SearchResults() 返回值，避免 nil/empty slice 导致 panic：
if len(cmd.Data) == 0 {
log.Println("No SEARCH response received")
return
}
results := cmd.Data[0].SearchResults()
if len(results) == 0 {
log.Println("No unseen messages found")
return
}
set := imap.NewSeqSet("")
set.AddNum(results...) // 安全调用? 总结
- 根本解法是规避超长响应：用 UID min:max 分段查询替代 1:* 全量扫描；
- BufferSize 是底层传输限制，非业务逻辑解决方案；
- 所有 SearchResults() 调用前必须做空值检查；
- 生产环境应结合 SINCE/BEFORE 等时间谓词进一步缩小搜索范围，兼顾性能与兼容性。
通过分页设计，你不仅能绕过行长度限制，还能提升响应速度、降低内存占用，并使代码具备良好的可扩展性。
