C++ 无原生 PDF 支持，需第三方库：libharu 适合快速生成（需手动处理中文 TTF），PODOFO 功能全但配置复杂，pdfium 最强但构建门槛高，poppler 提取文本易丢字因 PDF 自身缺陷。
C++ 本身不支持直接读写 PDF，必须依赖第三方库；没有“标准方案”，选错库会卡死在编译或中文乱码上。
PDF 生成用 libharu 还是 PODOFO？
想快速生成带文字、线条、简单表格的 PDF，libharu 上手快、静态链接友好、Windows 下免依赖；但不支持 Unicode 字体嵌入（中文需手动加载 .ttf 并调用 HPDF_UseUTFEnc）。PODOFO 功能更全（支持加密、已有 PDF 修改），但 CMake 配置麻烦，PoDoFo::PdfMemDocument 构造失败常因 OpenSSL 版本不匹配或未定义 PODOFO_LIBRARY。实际项目中，纯生成场景优先试 libharu；若要合并/解析已有 PDF，再切到 PODOFO。
-
libharu中中文显示必须调用HPDF_LoadTTFontFromFile+HPDF_AddPage后设置字体，漏一步就是方块 -
PODOFO的PdfFont* font = doc->GetFont("Arial", true)第二个参数为true才启用子集嵌入，否则中文字符可能被丢弃 - 两者都不处理 PDF/A 合规性，存档需求需额外加
HPDF_SetViewerPreference或用pdfium
pdfium 编译失败常见原因
pdfium 是 Chromium 的 PDF 引擎，功能最强（渲染、表单、JavaScript），但构建门槛最高。90% 的失败集中在 Ninja 生成阶段：GYP_GENERATORS=ninja build/gyp_pdfium.py 报错多半是 Python 路径含空格，或 Windows 上没关杀毒软件（它会锁 .obj 文件）。Linux 下容易忽略 clang 版本要求（必须 ≥14），而 macOS 的 xcode-select --install 不等于装了完整命令行工具——得运行 xcode-select --switch /Applications/Xcode.app 指向 Xcode 根目录。
- 错误信息
error: no member named 'to_string' in namespace 'std'→ 检查CXXFLAGS是否漏了-std=c++17 -
pdfium默认不导出 C API，要用FPDF_InitLibrary必须定义FPDFSDK_EXPORTS宏并链接pdfium.dll（Windows）或libpdfium.so（Linux） - 调试时看到
FPDF_LoadDocument返回nullptr，大概率是文件路径用了反斜杠\却没转义，或 PDF 损坏但FPDF_GetLastError()返回FPDF_ERR_SUCCESS（这是已知 bug，得靠fopen先校验文件可读）
用 poppler 提取文本为什么总丢字？
poppler 的 pdftotext 命令行好用，但 C++ 绑定 libpoppler-cpp 提取文本时，Page::getText() 返回空或断句错，通常不是代码问题，而是 PDF 本身没内嵌字体描述符或用了 Type 3 字体。此时强行调用 Page::search() 可能返回坐标但无对应文本内容。更稳的做法是先用 pdfinfo input.pdf 看输出里是否有 Tagged: yes 和 Form: none —— 前者说明结构化文本可用，后者避免表单字段干扰。
立即学习“C++免费学习笔记（深入）”；
- 提取前务必调用
PDFDoc::setEnableXFA(false)，否则含 XFA 表单的 PDF 会静默失败 -
TextOutputDev构造时传false关闭physicalLayout，否则多栏排版会被强行拉成一行 - 遇到加密 PDF，
PDFDoc构造后立即检查doc->isOk()，别等getPage(0)再崩
真正难的从来不是“怎么调函数”，而是 PDF 文件本身千奇百怪：字体嵌入不全、流压缩损坏、交叉引用表错位……建议所有操作前先用 qpdf --check input.pdf 过一遍，比在 C++ 里抓耳挠腮强十倍。
