recover对pdf排版异常完全无效——它只捕获panic，而pdf库默认以错误返回值（如setfont、image、cell返回的error）报告字体缺失、坐标越界等异常，需逐层校验err而非依赖recover。
Go PDF生成时recover根本捕获不到排版异常
直接说结论：recover对PDF排版异常完全无效——它只对panic起作用，而绝大多数PDF库（如unidoc、gofpdf、pdfcpu）在遇到字体缺失、坐标越界、图像解码失败等排版问题时，**默认不触发panic，而是返回错误或静默降级**。你用defer+recover包一层生成函数，几乎什么都抓不到。
真正该拦截的是PDF库的显式错误返回值
以gofpdf为例，所有排版操作（AddPage、SetFont、Cell、Image）都返回error；unidoc的WriteTo、AddPage也同理。这些错误才是排版异常的信号源。
-
SetFont失败通常意味着字体路径错、字体格式不支持（如ttf未注册）、或字体名拼写错误 -
Image返回image: unknown format说明图片后缀与实际格式不符（比如文件是.webp但扩展名写成.jpg） -
Cell或MultiCell在宽度超限且未启用自动换行时可能返回pdf: text width exceeds available width（取决于库版本） - 用
pdfcpu嵌入字体时若pdfcpu font embed命令出错，需检查TTF是否含合法CMap、是否被系统字体管理器锁定
什么时候recover才可能有用？极少数边界场景
仅当你自己写的排版逻辑主动panic，或第三方库内部有未处理的空指针/切片越界——但这属于bug，不是设计行为。例如：
// 危险示例：手动panic模拟崩溃
func renderBadCell(pdf *gofpdf.Fpdf, text string) {
if len(text) > 10000 { // 假设你加了这种校验
panic("text too long for PDF cell")
}
pdf.Cell(40, 10, text) // 正常调用
}
// 这样recover才能捕获
defer func() {
if r := recover(); r != nil {
log.Printf("PDF render panicked: %v", r)
// 降级为纯文本日志或占位图
}
}()
renderBadCell(pdf, hugeString)
但现实中，靠谱的PDF库不会靠panic报排版错；靠recover等于放弃错误类型判断，把nil pointer dereference和“字体没找到”混为一谈。
生产环境必须做的三件事
别信recover，盯紧错误链、预检资源、分层fallback：
- 所有PDF操作后立即检查
err != nil，尤其SetFont和Image——它们失败会导致后续内容全乱 - 生成前预加载字体：用
font.RegisterFont（unidoc）或pdf.AddFont（gofpdf）并验证返回值，不要等到WriteTo才暴露 - 对用户上传的图片，生成PDF前先用
image.DecodeConfig确认格式和尺寸，避免在PDF管道里解码失败
排版异常的本质是资源状态不一致，不是程序崩溃。盯着error流比守着recover管用十倍。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
