Go语言处理PDF需按任务选库：生成用gofpdf/gopdf，解析用pdfcpu或go-tika，改写/拆分用pdfcpu；gofpdf中文方块因未调SetFont或路径错误，MultiCell不自动分页需手动检测GetY并AddPage。
Go 里处理 PDF 没有“万能库”，得按任务类型选：生成用 gofpdf 或 gopdf，解析/提取文字优先用 pdfcpu + 外部 OCR 或 go-tika，改写/拆分用 pdfcpu 的 Go API。混用目标会导致编译失败或静默丢内容。
gofpdf 生成 PDF 时中文显示为方块
不是编码问题，是字体注册后没切换或路径错。常见错误包括：
- 只调了
AddFont("noto", "", fontPath)，但漏掉紧随其后的SetFont("noto", "", 12) - 字体文件路径用相对路径如
"./fonts/NotoSansCJKsc-Regular.ttf"，而二进制运行时工作目录不固定；应改用filepath.Join(filepath.Dir(os.Executable()), "fonts", "...") - 误用 Windows 自带的
simhei.ttf：部分版本含 DRM 头，gofpdf加载失败且不报错 - 单位设错（比如初始化用
"mm"，但字体大小仍按 pt 理解），导致文字挤成一团或超框
MultiCell 写长文本却只在第一页底部截断
MultiCell() 会自动换行，但**不会自动翻页**。光标移出页面边界后继续写，内容直接被裁掉，也不 panic。
- 每次调用前检查纵坐标：
y := pdf.GetY()，A4 高 842pt，留 50pt 页脚，安全上限 ≈ 792pt - 超限时手动翻页：
if y > 792 { pdf.AddPage(); pdf.SetY(50) } -
SetAutoPageBreak(true, 50)只对MultiCell()生效，且必须在AddPage()之后、首次MultiCell()之前调用 -
Cell()完全不换行也不分页，适合订单号这类固定长度字段；超宽直接截断，别指望它“自适应”
pdfcpu 提取页面却报 “invalid PDF” 或输出空目录
报错不是库坏了，而是输入文件本身有问题或命令参数没对齐。
立即学习“go语言免费学习笔记（深入）”；
- 先用
file your.pdf确认是真实 PDF；再用head -c 100 your.pdf看是否以%PDF-开头 - 加密 PDF 必须显式传密码：
pdfcpu extract -pw "123" -pages 3 input.pdf output/，否则直接报 invalid - 目标目录
output/必须已存在，pdfcpu不创建父级路径 - 页码从 1 开始，
-pages 5-2会静默忽略；-pages 2-5才合法 - 提取结果不含书签、表单、注释——它复制的是渲染层，不是结构层
想从 PDF 提取文字，但 gofpdf 和 pdfcpu 都返回空
gofpdf 是纯生成库，根本没有读能力；pdfcpu info 返回空元数据，不代表文件损坏，只是 PDF 原本就没嵌入 /Info 字典。
- 确认是否扫描件：
pdfcpu validate -v file.pdf看页数和对象数；若对象极少（ - 提取文字不要用
pdfcpu.ExtractPages：它只返回新 PDF 字节流，不含文本 - 轻量方案：用
go-tika（封装 Apache Tika）调本地 Tika Server，支持中英文混合识别 - 离线可控方案：用
exec.Command("tesseract", "input.png", "stdout", "-l", "chi_sim+eng")，配合golang.org/x/image提前转图
最常被跳过的环节是验证输入文件有效性——别急着写逻辑，先用 file、pdfcpu validate、head 三连确认 PDF 是否真能被工具链消费。生成和解析是两条平行路径，强行让一个库干两件事，只会卡在 silent failure 上。
