fiber框架默认不支持excel导出，因其定位为极简高性能web框架，仅处理路由与响应生命周期，不内置任何文件格式序列化逻辑；excel是复杂二进制格式，需依赖excelize等专用库手动构造http响应流。
直接用 Fiber 框架导出 Excel 文件不可行——它本身不提供 Excel 生成能力，必须搭配第三方库（如 excelize）并手动构造 HTTP 响应流。
为什么 Fiber 默认不支持 Excel 导出
Fiber 是一个极简、高性能的 Go Web 框架，只处理路由、中间件和响应生命周期，不内置任何文件格式序列化逻辑。Excel 是二进制结构（.xlsx）或特定格式文本（.xls），需要专门的解析/生成库，Fiber 不会也不该承担这部分职责。
常见误解是把“导出”等同于“返回 CSV”，但 CSV 不是 Excel 文件——它只是 Excel 能打开的一种纯文本格式，缺乏样式、多 Sheet、公式等关键特性。
-
excelize是目前 Go 生态最成熟、无 CGO 依赖、支持 .xlsx 全特性的库 - 若只要快速导出表格数据且兼容性要求低，可用
text/csv包生成 CSV，再设Content-Type: text/csv - 切勿尝试用 HTML 表格 +
Content-Type: application/vnd.ms-excel欺骗浏览器——现代 Excel 和 Edge/Chrome 已普遍拒绝这种非标准方式，且会丢失格式、公式、数字精度
用 Fiber + excelize 实现真实 .xlsx 导出
核心思路：在 Handler 中创建 *excelize.File，写入数据，调用 f.Write() 写入 c.Response().BodyWriter()，再设置正确的 Header。
- 必须调用
c.Response().Header.Set("Content-Type", "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet")，不是旧式vnd.ms-excel - 文件名需 URL 编码，否则中文名在 Safari 或部分 Chrome 版本中会乱码：
Content-Disposition: attachment; filename*=UTF-8''%E6%95%B0%E6%8D%AE.xlsx - 避免先写入磁盘再读取——直接流式写入响应体，节省内存和 I/O
- 若数据量大（>10 万行），需启用流式写入（
f.NewStreamWriter()），否则整张表加载进内存易 OOM
func exportHandler(c *fiber.Ctx) error {
f := excelize.NewFile()
// 写入数据...
if err := f.SetCellValue("Sheet1", "A1", "姓名"); err != nil {
return err
}
c.Response().Header.Set("Content-Type", "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet")
c.Response().Header.Set("Content-Disposition", `attachment; filename="data.xlsx"`)
return f.Write(c.Response().BodyWriter())
}
导出时容易踩的坑
很多开发者卡在响应头或流关闭时机上，导致下载文件损坏、空白或被浏览器拦截。
-
c.SendStatus(200)或c.JSON(...)后再调用f.Write(...)—— 会 panic，因为响应体已被提前提交 - 忘记设置
Content-Type，浏览器按text/plain处理，直接显示乱码二进制 - 用
c.Attachment()传本地路径——这会触发文件读取+拷贝，完全绕过excelize的流式能力，且不安全（路径注入风险） - 并发导出时复用同一个
*excelize.File实例——它不是 goroutine-safe 的，必须每个请求新建
真正要注意的是：Excel 导出本质是「构造二进制响应」，不是「生成文件」。所有操作必须在一次 HTTP 响应周期内完成，且不能和其它响应方法混用。流式写入的边界、Header 设置顺序、编码处理，三者缺一不可。
