高并发下excel导出必须异步化：立即返回任务id，后台用限流worker池处理，状态查内存/redis，下载走预签名url流式传输。
导出任务在高并发下容易拖垮服务，不是 Gin 不行，而是默认写法没做隔离和限流 —— 你得把“导出”从主请求流里摘出来，否则一个 30 秒的 Excel 导出就能让其他接口排队。
导出请求不能直接 blocking handler
常见错误是把生成文件逻辑全塞进 c.JSON() 前：读 DB、组装数据、写 Excel、返回文件。这会独占一个 goroutine 至少几秒到几十秒，虽不阻塞其他请求，但日志时间戳堆积、连接数飙升、内存持续上涨。
- ✅ 正确做法：立即响应客户端，后台异步执行导出，用唯一任务 ID 查询进度
- ❌ 错误示例：
c.File("report.xlsx")在 handler 里同步调用（尤其没设超时） - 注意
c.Copy()：若需在 goroutine 中访问c.Request或c.GetHeader()，必须先调用c.Copy()，否则可能 panic 或读到脏数据
用 channel + worker pool 控制并发导出数
不限制并发数的 goroutine 泛滥，比串行更危险：内存爆、DB 连接耗尽、CPU 打满。别依赖 “Go 自带并发”，得主动控量。
- 定义固定大小的 worker pool，比如 5 个长期运行的 goroutine 专门处理导出任务
- 所有导出请求发到同一个
chan ExportTask，worker 从 channel 取任务，避免新建 goroutine - 任务结构体里带上
context.Context并设置超时（如context.WithTimeout(ctx, 5*time.Minute)），防止单个导出卡死 - 避免用
sync.Map存任务状态 —— 高频读写易成瓶颈；改用map[string]*ExportResult+sync.RWMutex更可控
前端轮询 or WebSocket？优先选轻量轮询
WebSocket 对导出这类低频、单向通知场景是过度设计，且增加部署复杂度（反向代理需升级、连接保活、断线重连）。
- 推荐方案：/export/start 返回
{"task_id": "exp_abc123"}，前端每 2–3 秒 GET /export/status?task_id=exp_abc123 - status 接口必须快：只查内存 map 或 Redis，绝不查 DB；返回字段精简（
status: "processing"|"done"|"failed"、progress: 65、download_url: "/export/download?token=..."） - download_url 要带一次性 token，且后端校验 token 有效期（如 10 分钟）、绑定 task_id、用
http.ServeContent流式传输，避免整个文件 load 到内存
文件存储别放本地磁盘
多实例部署时，本地文件路径不一致，下载链接会 404；临时文件不清理还会撑爆磁盘。
- 导出文件存对象存储（S3/MinIO），返回预签名 URL；或用 Redis+内存缓存小文件（
- 若坚持用本地，必须挂共享存储（NFS），且加清理逻辑：启动时扫
/tmp/exports/*.xlsx，超 1 小时自动删 - Excel 库选
tealeg/xlsx或qax921/xlsx，它们支持流式写入；别用360EntSecGroup-Skylar/excelize的SaveAs()全量内存模式，大文件直接 OOM
真正难的不是“怎么导出”，而是“怎么不让导出影响别人”。任务隔离、资源节流、状态解耦，这三件事漏掉任何一环，高并发导出就是定时炸弹。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
