pdfcpu info报“invalid pdf”主因是文件截断、损坏、加密、pdf/a子集不支持或lzw压缩未启用；需用file和head验证格式，加密文档须显式传-password，v0.3.15+默认支持lzw。
pdfcpu 读取 PDF 元信息失败：为什么 pdfcpu info 报 “invalid PDF”？
常见原因是文件被截断、损坏，或实际是 PDF/A、加密 PDF、或带流压缩的 PDF（如 LZW）但未启用对应解码支持。pdfcpu 默认不处理加密文档，也不支持所有 PDF/A 子集。
- 先用
file your.pdf确认是不是真 PDF；再用head -c 100 your.pdf看开头是否为%PDF- - 若含密码，必须显式传入：
pdfcpu info -pw "secret" your.pdf，否则直接报错 - pdfcpu v0.3.15+ 才默认启用 LZW 解码；旧版需加编译标签
buildtags=lzw，否则解析含 LZW 压缩的流会 panic
用 pdfcpu 提取指定页生成新 PDF：pdfcpu extract 的边界行为
pdfcpu extract 不是“拆分”，而是“导出页面为独立 PDF 文件”；它不会修改原文件，但输出路径需手动指定，且页码从 1 开始（不是 0）。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 提取第 3 页：
pdfcpu extract -pages 3 input.pdf output/→ 输出为output/input_003.pdf - 提取连续页：
-pages 2-5合法；但-pages 5-2会静默忽略，不报错也不生成文件 - 目标目录
output/必须已存在，否则报open output/: no such file or directory，pdfcpu 不自动创建父级 - 若原 PDF 有书签或表单字段，提取后这些交互元素会丢失——pdfcpu 提取的是渲染后的页面内容，不是结构化对象
Golang 中调用 pdfcpu 库解析页面文本：别直接用 pdfcpu.ExtractPages
pdfcpu 的 Go API 没有内置文本提取能力。pdfcpu.ExtractPages 只做页面复制（类似命令行 extract），返回的是新 PDF 字节流，不含文字内容。
- 要提取文字，得换库：比如
unidoc/unipdf（商用需授权）或开源替代github.com/pdfcpu/pdfcpu/pkg/api+ 外部 OCR（如 tesseract） - 若坚持用 pdfcpu，可先用
pdfcpu validate确保 PDF 结构完好，再配合gofpdf或unipdf读取其输出 PDF 的内容 - 注意：pdfcpu 的 Go API 要求调用前初始化配置，漏掉
pdfcpu.SetLogger(...)或pdfcpu.AddDefaultValidation()可能导致后续操作 panic
性能与内存：大 PDF（>50MB）用 pdfcpu 提取页面时卡住或 OOM
pdfcpu 默认加载整份 PDF 到内存解析，对大文件很敏感。它不支持流式读取，也没有分块处理机制。
- 用
pdfcpu validate -v input.pdf查看页数和对象总数，若超 10k 个间接对象，大概率触发 GC 压力 - 限制并发：避免在 goroutine 中密集调用
pdfcpu.ExtractPages，每个调用都新建 PDFContext，开销不小 - 临时方案：改用命令行调用并加
ulimit -v 524288（限制 512MB 虚拟内存），比纯 Go 调用更稳 - 真正的大文件场景，建议预处理：用
pdftk或qpdf先线性化（linearize）或解压流，再交给 pdfcpu
pdfcpu validate -v 和原始 PDF 规范交叉比对。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
