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）应该 embedexporterBase，并在构造时传入自己的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，导出就静默失败。
