pdfcpu读取pdf元信息返回空是因为文件本身未嵌入/info字典——该字典在pdf中是可选的，可能被清除；需用validate验证结构、dump确认是否存在/info，再用update补全。
pdfcpu 读取 PDF 元信息为什么返回空？
多数人用 pdfcpu info 看不到作者、标题等字段，不是命令错了，而是 PDF 文件本身没嵌入这些元数据——它和 Word 不同，PDF 的 /Info 字典是可选的，甚至可能被工具清除过。
实操建议：
- 先用
pdfcpu validate -v file.pdf确认文件结构合法，避免后续操作全失败 - 用
pdfcpu dump file.pdf查看原始对象，搜索/Info关键字，确认是否存在该字典 - 若需补全元信息，用
pdfcpu update -author="xxx" -title="xxx" file.pdf，注意这会生成新文件，原文件不变 - 某些扫描型 PDF（如 OCR 后导出）压根没有文本层，
pdfcpu的 info 命令仍能运行，但提取文字会直接失败——得换方案
gofpdf 能不能用来提取文字？
不能。gofpdf 是纯生成库，设计目标就是“写 PDF”，不带解析能力。它连页面尺寸都要手动算，更别说逆向还原文字坐标和字体映射了。
常见错误现象：调用 gofpdf.New 后试图读 .Parse 或 .Read 方法，编译报错或 panic，因为根本不存在这些函数。
立即学习“go语言免费学习笔记（深入）”；
替代路径：
- 提取文字优先选
unidoc（商业授权）或github.com/benjamintf1/pdf（MIT，轻量但仅支持简单布局） - 若 PDF 含扫描图+OCR 层，
unidoc可能漏字；此时得配合tesseractCLI + Go 的exec.Command调用，但要处理语言包路径和图像预处理 -
unidoc的pdf.Reader默认跳过加密 PDF，遇到permission denied错误时，先用pdfcpu decrypt解密再读
用 pdfcpu 提取文本时中文乱码怎么调？
pdfcpu 本身不渲染、不处理字体映射，它提取的是 PDF 内容流里的原始字符串。乱码根源在字体描述缺失或 CID 编码未正确关联到 Unicode。
关键判断点：运行 pdfcpu extract -text file.pdf 后输出含大量 或空格，大概率是内嵌字体没声明 ToUnicode CMap，或用了非标准子集名（比如 F1 而非 /F1）。
能做的有限，但可试：
- 加
-v参数看日志里是否报unknown font或no ToUnicode—— 这是明确信号 - 用
pdfcpu dump file.pdf | grep -A5 "FontDescriptor"检查字体是否含/Encoding /Identity-H和/ToUnicode流 - 若无
ToUnicode，基本无解；强行转可用github.com/klippa-app/go-pdfium（基于 PDFium，支持部分字体回退策略），但体积大、CGO 依赖强 - 别碰
pdfcpu config set fontdir，它只影响渲染输出，对文本提取无效
并发读多个 PDF 时 CPU 占满还 panic
pdfcpu 默认启用多 goroutine 解析，但它的内部对象池和缓存不是完全并发安全的——尤其在高并发调用 pdfcpu.ExtractText 时，容易触发 sync.Pool 误复用或内存越界。
性能真实瓶颈不在 IO，在于 PDF 解析器反复初始化字体解析器和 CMap 表。每个文件都从头加载，没共享缓存。
稳妥做法：
- 用
sync.Once初始化一次pdfcpu.Config，禁用自动配置：cfg := pdfcpu.NewDefaultConfig(); cfg.ParseMode = pdfcpu.PARSE_MODE_STRICT - 限制并发数，用
semaphore控制同时解析不超过 3–4 个，比无脑go func(){}()稳定得多 - 避免在循环里反复
os.Open+pdfcpu.ExtractText，改用bytes.NewReader(data)预读全部内容进内存，减少系统调用抖动 - 如果只是查页数或元信息，用
pdfcpu.GetNumPages这类轻量函数，别走完整提取流程
最麻烦的其实是 PDF 版本混杂：PDF 1.7 和 PDF 2.0 对对象流（ObjStm）的处理逻辑不同，同一份代码在不同文件上表现不一，必须单个文件单独测通再并行。
