beego项目导出百万数据卡死，根本原因是默认用excelize等库一次性全量加载数据至内存（100万行约500mb+），触发go runtime gc压力爆表；beego-admin v2.0.1虽封装导出功能，但未实现流式控制，必须改用streamwriter逐块写入、游标分页查询、每5000行调用flush，并禁用limit offset,size。
Beego 项目里导出百万数据为什么卡死？
不是 Beego 慢，是默认用 excelize 或 xlsx 库一次性把所有行 load 进内存，100 万行 ≈ 500MB+ 内存占用，Go runtime 直接 GC 压力爆表。beego-admin v2.0.1 虽封装了导出功能，但底层没做流式控制，遇到大数据量就退化成“等它跑完”模式。
真正可行的路只有一条：绕过全量加载，用生成器式逐块写入。Go 生态里目前只有 excelize 支持边写边 flush，且必须配合 SetRow + 手动分批 + Flush 调用。
- 别用
f.SetSheetRow一次性塞整张表——这是内存炸弹 - 每写 5000 行调一次
f.Flush()，释放底层 buffer - 数据库查询必须用游标（
SELECT * FROM t WHERE id > ? ORDER BY id LIMIT 5000），禁用LIMIT offset, size - Beego 的
Controller.Ctx.ResponseWriter要设好Content-Disposition和Content-Type，否则浏览器不触发下载
如何让 beego-admin 的 Excel 导出支持流式分页？
beego-admin 当前导出逻辑在 controllers/base.go 或类似位置，通常直接调 excelize.NewFile() → 填数据 → WriteToResponse。要改造成流式，核心是拆掉“生成完整文件再响应”的链路，改成边生成边写入 HTTP body。
实际操作只需三处修改：
- 把
excelize.File替换为excelize.StreamWriter，初始化时传入controller.Ctx.ResponseWriter - 数据库查询改用游标分页：记录上一批最大
id，下一批查WHERE id > last_id ORDER BY id LIMIT 5000 - 每次写完一个批次后，显式调用
sw.Flush()，并检查http.CloseNotifier（如果客户端断开可提前退出）
注意：StreamWriter 不支持合并单元格、公式、样式——这些得靠模板预置或导出后二次处理，流式和富样式不可兼得。
导入大 Excel 文件时 panic: runtime out of memory 怎么破？
原因很直接：beego-admin 默认用 excelize.LoadFile 把整个 .xlsx 解压进内存再解析，一个 100MB 的 Excel 解压后可能占 800MB RAM。这不是 Beego 的锅，是库选型问题。
解决方案只有换解析策略：
- 改用
go-excel（非官方，轻量流式读取）或roaring/excel（专为大数据设计） - 禁用图片、注释、宏等非必要内容：在
excelize.Options中设IgnoreImage = true、IgnoreComment = true - 导入接口加
Content-Length校验，拒绝 > 50MB 的上传文件（前端也应限制） - 关键：导入必须走异步任务（如
beego.BeeApp.AddTask或对接 Redis 队列），不能阻塞 HTTP 请求协程
为什么用 beego-admin 就没法做字典转换和表头注解？
因为 beego-admin 是 Go 语言项目，而 @ExcelProperty、@DictConvert 这类能力是 Java 的 EasyExcel / RuoYi Office 基于 JVM 注解反射实现的。Go 没有运行时注解反射，也没有像 Spring 那样的 AOP 机制，所以“声明式表头 + 自动码值转换”在 Go 里天然不存在。
替代方案是结构体字段加 tag，例如：
type User struct {
ID int `xls:"id"`
Status int `xls:"status,dict=enable_disable"` // 触发字典映射
Name string `xls:"name"`
}
但这需要你手写解析逻辑去读 tag、查字典表、替换值——beego-admin 没内置这个能力，得自己补一层 XlsMapper 工具类。最容易被忽略的是：字典映射必须缓存（比如用 sync.Map 存 map[int]string），否则每行都查 DB，性能反而更差。
