Gopdf 不适合高并发微服务中生成复杂中文电子发票，因其不支持 TrueType 字体子集嵌入，中文渲染易乱码或空白，且实例非 goroutine-safe，频繁新建易致内存泄漏。
直接说结论：Gopdf 不适合在高并发微服务中作为主力电子发票生成引擎，尤其当发票需含复杂样式、中文字体、表格对齐或数字签名时——它底层不支持 TrueType 字体子集嵌入，中文渲染容易乱码，且并发生成时内存泄漏风险明显。
为什么 Gopdf 生成带中文的发票经常乱码或空白
Gopdf 默认只支持内置的 Helvetica、Courier 等无衬线西文字体，不自带中文字体解析逻辑。即使你用 pdf.AddTTFFont() 加载 .ttf 文件，它也不会自动处理 Unicode 范围映射和字形子集提取，导致：
- 加载的中文字体文件路径错误（比如相对路径在 Docker 容器内失效）
- 字体文件本身不含 GB2312/UTF-8 映射表，
pdf.SetFont("simhei", "", 12)看似成功，实际绘制时返回空字形 - 同一字体多次调用
AddTTFFont()会重复注册，触发内部 fontID 冲突，后续WriteText()直接 panic
实操建议：必须提前用 font.FontMap 手动注册字体别名，并确认 TTF 文件已通过 embed.FS 或挂载卷方式可靠注入运行时环境；避免在 handler 中动态加载字体，应在服务启动时一次性完成。
并发下 Gopdf 实例复用与内存泄漏陷阱
gofpdf.NewCustom(&gofpdf.Config{Unit: "pt", Orientation: "P", PageSize: gofpdf.SizeType{W: 595.28, H: 841.89}}) 创建的实例不是 goroutine-safe 的，且内部维护大量临时缓冲区（如 pdf.buf、pdf.pages）。常见错误写法：
立即学习“go语言免费学习笔记（深入）”；
// ❌ 错误：每次请求都 new 一个 pdf，不 Close()
func generateInvoice() []byte {
pdf := gofpdf.NewCustom(...) // 每次都新建
pdf.AddPage()
pdf.Cell(40, 10, "发票标题")
return pdf.OutputBytes() // 内存未释放，buf 残留
}
正确做法是复用单个 *gofpdf.Fpdf 实例，但必须配合 pdf.Reset() 清理状态，且注意：
-
Reset()不会清空已注册字体，所以字体注册只需一次 -
Reset()后需重新调用AddPage()，否则Cell()报page not added - 若发票模板差异大（如横版/竖版、多页/单页），建议按模板类型维护多个预热好的 pdf 实例池，而非强行复用一个
替代方案比硬啃 Gopdf 更省力
如果发票结构固定（如含 logo、表格、金额合计、二维码），优先考虑 HTML → PDF 方案：
- 用
go-wkhtmltopdf调用本地 wkhtmltopdf 二进制（需容器内安装），支持 CSS 布局、@font-face 中文字体、媒体查询适配打印 - 轻量级可选
chromedp+ headless Chrome，渲染精度更高，但资源开销大 - 若必须用原生 PDF 库，
unidoc/unipdf（商用许可）或开源分支pdfcpu（仅支持已有 PDF 编辑，不适合从零生成）
真正需要 Gopdf 的场景其实很窄：超低延迟、极简文本票据（如物流面单）、离线边缘设备——这时才值得花时间 patch 字体子集逻辑或封装安全复用层。
最常被忽略的一点：发票生成后必须校验 PDF 结构有效性（比如用 pdfcpu validate CLI 或 github.com/unidoc/unipdf/v3/model.ValidatePdf），Gopdf 输出的 PDF 在某些字体组合下看似正常，实则缺失 FontDescriptor 导致 Adobe Reader 提示“字体损坏”，而浏览器预览又不报错。
