应禁用压缩并流式写入：pdf.compress = false 后调用 pdf.writeto(out io.writer)，避免 pdf.output() 加载全量内存导致 oom。
gofpdf.Output() 默认压缩导致 OOM 怎么办
生成 30+ 页 PDF 时，pdf.Output() 会默认启用压缩，并把整个 PDF 内存缓存后再编码，极易触发 runtime: out of memory。这不是你代码写错了，是库的默认行为在大文档场景下不适用。
- 初始化 PDF 实例后立即关闭压缩：
pdf.Compress = false - 不要调用
pdf.Output()得到[]byte再写磁盘——这一步就已把全部内容加载进内存 - 改用
pdf.WriteTo(out io.Writer)直接流式落盘，底层走的是分块写入，内存占用稳定在 KB 级别
为什么不能用 os.WriteFile 写 gofpdf 输出
os.WriteFile 要求输入是 []byte，而 pdf.Output() 返回的字节切片已是完整 PDF 的内存镜像。对几十 MB 的报表来说，等于强制 Go 分配一块同等大小的堆内存，GC 压力陡增，服务可能直接卡死或被系统 OOM Killer 杀掉。
- 永远避免
data, _ := pdf.Output(); os.WriteFile("out.pdf", data, 0644)这类模式 - 若必须拿到
[]byte（比如要发 HTTP 响应体），请确认文档页数可控（ - 生产环境导出报表，优先走
WriteTo()+os.File或io.MultiWriter（如同时写磁盘+记录日志）
流式写入 PDF 文件的最小可靠模板
核心就是三件事：禁用压缩、打开文件、WriteTo。没有多余抽象，不依赖中间 buffer，也不需要手动分块。
pdf := gofpdf.New("P", "pt", "A4", "")
pdf.Compress = false // 关键
// 添加内容...
pdf.AddPage()
pdf.SetFont("Arial", "", 12)
pdf.Cell(40, 10, "Hello World")
// 流式写入磁盘
out, err := os.Create("report.pdf")
if err != nil {
log.Fatal(err)
}
defer out.Close()
err = pdf.WriteTo(out) // 不是 Output()！
if err != nil {
log.Fatal(err)
}
-
WriteTo()内部使用 32KB 缓冲区循环写入，和io.Copy同一设计哲学 - 文件路径含目录时，需提前调用
os.MkdirAll(filepath.Dir("path/to/report.pdf"), 0755) - 若需确保数据真正落盘（比如防止断电丢数据），可在
WriteTo()后加out.Sync()，但会增加延迟
gopdf 和 unidoc 库是否也支持流式写入
不完全一样。gopdf 的 SaveToFile() 是同步写入，内部仍会构建完整字节切片；unidoc（即 github.com/unidoc/unipdf/v3）提供 WriteToFile()，但默认仍走内存缓冲，需配合 pdf.Writer 手动控制输出流——不如 gofpdf.WriteTo() 直观可靠。
- 如果你已在用
gofpdf，坚持用WriteTo()就够了，无需切换库 - 若需读取+修改已有 PDF（比如填表、加水印），
unidoc是更合适的选择，但它不是为“生成→落盘”这个单向流程优化的 - 流式写入的关键不在库名，而在是否绕过“全量内存缓冲”这一环节——
gofpdf.WriteTo()是目前 Go 生态中对此场景最干净的实现
ioutil.ReadAll 就算“流式”，但 PDF 库自身的 Output() 方法可能比 HTTP Body 更隐蔽地吃内存。禁用压缩 + 拒绝 []byte 中间态，这两步缺一不可。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
