当使用 go-imap 库执行 `uidsearch` 时，若服务器返回极长的 uid 列表（如数万个连续 id），会因单行长度超出默认 65536 字节缓冲限制而触发 “line too long” 错误，进而导致后续解析 panic；需通过分页搜索或调整协议行为规避。
该错误源于 go-imap 库对 IMAP 协议行长度的严格限制：其底层 transport.go 中定义了全局常量 imap.BufferSize = 65536，既用作网络 I/O 缓冲区大小，也作为 物理行（physical line）的最大长度。虽然 RFC 2683 建议客户端将行长控制在约 1000 字节以内以保证兼容性，但许多 IMAP 服务器（如 Dovecot、Gmail 后端）在响应 SEARCH 或 UID SEARCH 时，会将成千上万个 UID 拼接为单行返回（如示例中超过 12000 个 UID 导致行长达数万字符），直接突破 BufferSize 边界，引发 imap: line too long 错误。
更严重的是，该错误发生后，cmd.Data[0].SearchResults() 可能返回空切片或不完整数据，导致后续 set.AddNum(...) 调用时传入空 slice，而 imap.NewSeqSet("").AddNum() 在空参数下可能触发内部索引越界（index out of range），造成二次 panic。
✅ 推荐解决方案：避免单次全量 SEARCH，改用分页/范围搜索
IMAP 协议本身不支持分页 SEARCH，但可通过缩小搜索范围 + 迭代实现等效效果。例如，按 UID 区间分批查询未读邮件：
// 分段搜索 UID（建议每批 ≤ 1000 个 UID，确保响应行不超长）
const batchSize = 1000
// 先获取邮箱最大 UID，缩小初始范围
status, _ := c.Status("INBOX", []string{"UIDNEXT", "UIDVALIDITY"})
maxUID := status["UIDNEXT"].(uint32) - 1 // 近似当前最大 UID
var allUIDs []uint32
for start := uint32(1); start <= maxUID; start += batchSize {
end := start + batchSize - 1
if end > maxUID {
end = maxUID
}
// 构造区间搜索条件：UNSEEN UID 值范围
searchCmd := fmt.Sprintf("%d:%d UNSEEN", start, end)
cmd := ReportOK(c.UIDSearch(searchCmd))
if len(cmd.Data) > 0 && len(cmd.Data[0].SearchResults()) > 0 {
allUIDs = append(allUIDs, cmd.Data[0].SearchResults()...)
}
}⚠️ 不推荐方案（仅作说明）：修改 BufferSize
虽可全局覆盖 imap.BufferSize（如设为 1024 * 1024），但存在风险：
- 违反 RFC 2683 实践建议，可能与老旧服务器不兼容；
- 增加内存占用且无法根本解决线性增长的响应膨胀问题；
- mxk/go-imap 已归档，不再维护，长期项目应迁移至更活跃库（如 emersion/go-imap）。
? 额外健壮性增强
- 始终检查 cmd.Data 长度和 SearchResults() 结果有效性：
if len(cmd.Data) == 0 { log.Println("No SEARCH response data") continue } uids := cmd.Data[0].SearchResults() if len(uids) == 0 { continue // 本批次无匹配 } set.AddNum(uids...) - 对 UIDFetch 使用 imap.SeqSet 时，确保 set 非空再执行 fetch，避免无效请求。
? 总结：line too long 是 go-imap 对协议合规性的硬性校验，而非 bug。正确做法是主动适配 IMAP 的流式设计逻辑——用范围约束替代全量扫描，兼顾兼容性、性能与稳定性。
