Excel大文件导出panic常见于内存耗尽、第三方库越界、并发写共享资源；recover必须置于导出goroutine内部首行，失败后立即返回，不可继续操作文件；推荐流式写入、数据校验、分批导出等前置防护措施。
Excel大文件导出时 panic 的常见来源
导出百万行 Excel 时，panic 多来自三类场景：内存耗尽（runtime: out of memory）、第三方库内部越界（如 tealeg/xlsx 对 sheet 行数硬限制）、或并发写入共享资源（比如未加锁的 map 或 slice）。这些 panic 不会自动被上层 handler 捕获——尤其当导出逻辑跑在独立 goroutine 中时，主线程完全感知不到。
recover 必须写在导出 goroutine 内部
很多人把 recover 放在 HTTP handler 函数里，但导出逻辑若用 go exportToExcel(w, data) 启动新协程，handler 里的 defer+recover 就彻底失效。子协程 panic 会直接终止该 goroutine，且不传播，但可能留下半截文件、未关闭的 http.ResponseWriter 或泄漏的 goroutine。
-
defer func() { if r := recover(); r != nil { log.Printf("export panic: %v", r) } }()必须出现在导出函数体第一行，且该函数本身由go启动 - 不要依赖“全局 recover”——
init()里注册的defer只对init所在 goroutine 有效 - 如果用
sync.WaitGroup等待导出完成，recover也得在被WaitGroup.Add(1)的那个函数里
recover 后不能继续写 Excel 文件
一旦触发 panic（比如 xlsx.File.AddSheet 内部因内存不足崩溃），文件对象状态大概率已损坏。此时 recover() 成功只代表控制流回来了，不代表 file 还能安全调用 Write 或 Save。
- 务必在
recover分支中立即返回，**不要**尝试file.Close()或w.Write() - 清理动作（如删除临时文件、释放缓冲区）应放在导出函数开头的另一个
defer里，与recover分离 - 示例结构：
func exportWorker(w http.ResponseWriter, data [][]string) { tmpFile := createTempXLSX() defer os.Remove(tmpFile) // 安全清理，无论是否 panic defer func() { if r := recover(); r != nil { log.Printf("export failed: %v", r) http.Error(w, "导出失败，请重试", http.StatusInternalServerError) return // 不再执行后续任何 write 操作 } }() f := xlsx.NewFile() sheet, _ := f.AddSheet("data") for _, row := range data { sheet.AddRow().AddCell().SetValue("...") // 此处可能 panic } f.Save(tmpFile) // ... 后续 send file }
大文件导出更推荐替代方案而非 rely on recover
recover 是兜底手段，不是设计原则。真正稳定的导出应避开易 panic 路径：
立即学习“go语言免费学习笔记（深入）”；
- 用流式写入库（如
qax911/excel-stream），避免一次性加载全部数据进内存 - 提前校验数据规模：
if len(data) > 100000 { http.Error(w, "数据量超限", http.StatusBadRequest); return } - 用
runtime/debug.FreeOSMemory()在导出前主动释放，降低 OOM 概率（仅作缓解） - 最关键：把导出拆成小批次，每批单独
recover，失败只影响当前批次而非整个文件
recover 能防止进程退出，但救不了已损坏的 Excel 结构或客户端收到的乱码响应——这些都得靠前置约束和分块设计来规避。
