Beego中用gofpdf生成发票PDF需手动加载中文字体、禁用Cell()、用CellFormat/MultiCell输出中文，Controller中应先Output(nil)获取字节再ServeBinary，电子签名需RSA+SHA256结构化摘要并嵌入PDF，每次请求必须新建Fpdf实例防并发污染。
Beego 中如何用 gofpdf 生成带发票样式的 PDF
Beego 本身不内置 PDF 渲染能力，必须引入第三方库；gofpdf 是目前最稳定、中文支持较好、且能与 Beego HTTP 流程自然衔接的选择。关键不是“能不能”，而是“怎么避免字体乱码和布局偏移”。
常见错误现象：gofpdf: font not found 或中文显示为方块、表格列宽错位。这是因为 gofpdf 默认不带中文字体，且不自动处理 UTF-8 字符宽度。
- 必须手动加载支持 GBK/UTF-8 的中文字体（如
simhei.ttf），调用pdf.AddFont()并指定uni编码类型 - 所有中文文本必须用
pdf.CellFormat()或pdf.MultiCell()，禁用pdf.Cell()（它只支持 ASCII） - 表格绘制建议用
pdf.SetX()+pdf.SetY()手动定位，别依赖自动换行——发票字段长度固定，硬坐标更可控
Beego Controller 里如何安全返回 PDF 流而不阻塞请求
发票合成是 CPU 密集型操作，直接在 HTTP handler 里调用 pdf.Output() 容易导致超时或 goroutine 泄漏。核心是：PDF 生成必须与响应写入解耦，但又不能丢掉上下文（如用户 ID、发票号）。
- 不要在
Controller.Get()里直接pdf.Output(io.Writer)写入this.Ctx.ResponseWriter，除非你已设好this.Ctx.Output.Header("Content-Type", "application/pdf")和"Content-Disposition" - 更稳妥的做法：先用
pdf.Output(nil)得到[]byte，再调用this.Ctx.ServeBinary(data, "invoice_20241105.pdf") - 若发票内容较大（>5MB），考虑改用
io.Pipe()配合 goroutine 流式写入，避免内存峰值过高
如何让发票 PDF 包含电子签名和校验码（防篡改）
纯视觉水印没法律效力，真正可用的电子发票必须含可验证签名。Beego 不提供签名工具链，需自行集成 crypto/sha256 + crypto/rsa，并在 PDF 文字层下方嵌入 Base64 编码的签名摘要。
- 签名原文应为结构化字符串，例如：
fmt.Sprintf("%s|%s|%s|%s", invoiceNo, amount, taxAmount, issueDate)，而非整个 PDF 二进制 - 用私钥签名后，将
base64.StdEncoding.EncodeToString(signature)插入 PDF 固定位置（如右下角 8 号字体灰色文字），并确保该区域不被后续渲染覆盖 - 校验码建议额外生成一个独立字段（如
verify_code），用 SHA256(invoiceNo + secretKey) 截取前 8 位，方便人工核验
并发生成发票时 Beego 日志和 PDF 输出容易混乱怎么办
多个请求共用同一个 gofpdf.Fpdf 实例会导致字体状态、坐标、颜色等上下文污染，日志里出现“invalid page number”或空白 PDF 就是典型表现。
-
gofpdf.NewPdf()必须每次请求都新建，不能复用全局变量或单例 - Beego 的
this.Ctx.Input.GetData()不可用于跨 goroutine 传参；PDF 任务若异步执行，需显式把必要参数（如invoiceID,templateType）作为函数参数传入 - 日志建议用
beego.Info("pdf_gen", "invoice_id", invoiceID, "cost_ms", elapsed)结构化输出，避免多行日志被并发冲散
字体路径、私钥读取、模板数据加载——这些看似配置的事，实际在并发场景下最容易因缓存或共享状态出问题。别省那几毫秒初始化时间。
