Golang模板方法模式在数据导出(PDF/Excel)流中的应用

go中用组合+接口+非导出base Struct模拟模板方法模式，将preparedata、validate等稳定步骤封装在base中，render等差异逻辑通过函数字段注入，exporter接口仅声明可变方法，避免继承与空实现。

Go 模板方法模式怎么避免导出逻辑重复？

导出 pdf 和 excel 时，共用数据准备、权限校验、分页参数解析，但渲染逻辑完全不同——硬写两套会迅速失控。模板方法模式在这里不是炫技，是把 PrepareData、Validate、BuildHeader 这类稳定步骤抽成骨架，把 RenderPDF 和 RenderExcel 留给子类型实现。

关键不是“用模式”，而是明确哪些函数必须由子类实现、哪些可以默认提供。比如 Validate 大概率通用，但 WriteOutput 必须各自实现，因为 pdf.Writer 和 xlsx.File 完全不兼容。

• PrepareData 建议定义为模板方法里的公共步骤，子类只调 super.PrepareData()，避免漏掉缓存预热或字段脱敏
• 不要在模板基类里 new 具体的文件对象（如 gofpdf.New 或 xlsx.NewFile），这会让测试难 mock，也违反依赖倒置
• 如果导出要支持流式响应（http chunked），WriteOutput 接口必须接收 io.Writer，而不是返回 []byte —— 否则大文件直接 OOM

为什么 Go 里没法直接写 abstract class？

Go 没有继承关键字，所谓“模板方法”靠的是组合 + 接口 + 非导出字段模拟。常见错误是把所有方法都塞进一个 Interface，结果实现方被迫补一堆空方法，或者误以为实现了接口就自动获得骨架逻辑。

正确做法是定义两个东西：Exporter 接口只声明可变部分（如 Render(io.Writer) Error），再提供一个非导出的 exporterBase struct 封装公共流程，用函数字段（如 renderFunc func(io.Writer) error）注入差异逻辑。

立即学习“go语言免费学习笔记（深入）”；

• 别把 exporterBase 设计成导出类型，否则用户会误以为能直接 new 它；它只是内部协调器
• 每个具体导出器（如 PDFExporter）应该 embed exporterBase，并在构造时传入自己的 Render 实现
• 如果需要共享状态（如总记录数、当前页码），存在 exporterBase 里，不要让每个子类自己维护一份

HTTP 流式导出时，WriteHeader 和 Flush 的顺序踩坑点

模板方法跑完 PrepareData 后，往往要立刻写 HTTP header，但很多人在 Render 执行中才写，导致浏览器卡住等完整响应。更糟的是，在 RenderPDF 里反复调 Flush，而底层 http.ResponseWriter 不一定支持 chunked（比如某些 reverse proxy 会缓冲）。

• 必须在调 Render 前完成 w.Header().Set("Content-Disposition", ...) 和 w.WriteHeader(200)
• PDF 导出一般不支持真流式（gofpdf 要求内存生成完整 buffer），所以 RenderPDF 应该写完整 []byte 再一次性 w.Write；Excel（tealeg/xlsx 或 qax-os/excelize）才适合边写边 Flush
• 用 ResponseWriter 做流式输出前，先检查 if f, ok := w.(http.Flusher); ok { f.Flush() }，别假设一定可用

Excel 导出用 excelize 还是 tealeg/xlsx？

两者 API 差异直接影响模板方法的设计粒度。excelize 更现代，支持流式写入（f.NewStreamWriter），适合大数据量；tealeg/xlsx 简单但内存占用高，且不支持边写边 flush。

如果你的模板方法约定 “子类负责调 WriteRow”，那用 excelize 可以让 RenderExcel 直接操作 *xlsx.StreamWriter，而 tealeg/xlsx 就得改成 “子类返回 [][]interface{}，基类统一写入”——后者容易爆内存。

• 选 excelize：在 RenderExcel 里调 sw.SetRow，每写 1000 行手动 sw.Flush()
• 选 tealeg/xlsx：只用于小数据（RenderExcel 返回二维切片，由基类用 xlsx.File.AddSheet 统一处理
• 别混用：同一个项目里同时引入两个库，会导致 go mod 版本冲突和二进制体积膨胀

最易被忽略的是错误传播路径——模板方法里 PrepareData 出错，应该中断后续流程并返回具体 error，而不是吞掉或转成 panic。HTTP handler 里 recover 了 panic，但没处理好 error，导出就静默失败。