PDFiumSharp 是读取 PDF 页数最轻量且无依赖冲突的方案——它仅封装 Google PDFium，跳读 trailer 字典，毫秒级获取页数，无需加载全文。
用
读取页数最轻量且无依赖冲突
直接上结论：别碰
（已停更、.net 6+ 兼容差），也别硬啃
（java 项目，
c#
调用麻烦）。
是目前最干净的选择——它只是对 google pdfium 的 c# 封装，不带渲染逻辑，纯解析，开箱即读页数。
常见错误是以为必须“加载整个文档”才能拿到页数，其实 PDF 的页数信息藏在文件末尾的
字典里，
的
就是精准跳过去读这一小段，毫秒级完成。
安装：
必须调用
一次（通常放
或
），否则抛
路径传错会静默返回 0，不是异常——检查
再调用
为什么
和
不适合只读页数
这两个库定位是“生成 PDF”，解析只是副产物。它们会在打开时尝试解析字体、资源、结构树，哪怕你只想要页数，也会触发完整解析流程。
实测对比：一个 12MB 含扫描图的 PDF，
耗时
，
耗时
且内存涨 120MB；
根本不提供页数 API，得自己扒底层
——那不如直接用原生封装。
免费版有页眉水印，商用需授权
的
是为渲染准备的，没公开
访问接口
两者都依赖本地原生 DLL（Windows/Linux/macOS 分开部署），而
的 nuget 包已含对应平台二进制
+ 正则硬解析 PDF 页数？别试
有人想绕过库，直接读文件找
或
对象。PDF 是二进制格式，开头可能有 %PDF-1.7，后面跟着乱码流和压缩对象，文本搜索大概率失败。
C知道
CSDN推出的一款AI技术问答工具
下载
真实 PDF 文件中，
可能出现在任意对象里（比如目录树节点），也可能被加密、被 FlateDecode 压缩、甚至被故意错位写入干扰字段。正则匹配
在测试文件上能跑通，上线后遇到扫描件转 PDF 或 Acrobat 生成的文件就崩。
PDF 规范允许页数存于
或间接引用链中，必须走标准解析器遍历
即使文件未加密，
按 UTF-8 读会把二进制段当非法字符跳过，关键字直接丢弃
没有校验 offset 和 xref 表，找到的数字可能是注释、字符串内容或旧版本残留
跨平台部署时注意
的运行时位置
底层依赖
动态库，Linux/macOS 下不会自动从 nuget 包复制到输出目录，运行时找不到会报
。
Windows：nuget 自动处理，无需额外操作
Linux：确保
在
中，或发布时用
并手动拷贝 so 文件到
目录
macOS：同理，用
修正 dylib 路径，或改用
（体积增大 ~40MB）
最容易被忽略的是 Docker 多阶段构建：build 阶段装了 libpdfium，runtime 阶段镜像里没它——必须显式
或用
（Alpine）这类基础镜像。
PDFiumSharpitextsharppdfboxpdfiumsharptrailerPDFiumSharpGetPageCount()dotnet add package PDFiumSharpPDFium.Initialize()Main()StartupSystem.DllNotFoundExceptionFile.Exists()PDFium.Initialize();
using var doc = PDFium.OpenDocument("report.pdf");
int pageCount = doc.GetPageCount(); // 不会解码内容，不占内存QuestPDFIronPDFPDFiumSharp3msIronPDF850msQuestPDFPdfiumCoreIronPDFQuestPDFDocument.Load()TrailerPDFiumSharpStreamReader/Count/Pages/Count/Count\s+\d+Root/Pages/CountStreamReaderlibpdfiumPDFiumSharplibpdfiumDLL load failedlibpdfium.soLD_LIBRARY_PATHdotnet publish -r linux-x64 --self-contained falsepublish/install_name_tool--self-contained trueCOPYapk add pdfium-dev