iTextSharp 5.x 合并 PDF 时中文乱码或内容丢失，因默认不嵌入中文字体，须显式注册 Unicode 字体（如 simsun.ttc）并用 copy.GetImportedPage() 替代 GetPageN()；含表单应选 PdfSmartCopy；书签需手动重映射；推荐升级至 iText7，其 PdfMerger 原生支持合并书签、字体及表单。
用 iTextSharp 合并 PDF 时为什么中文乱码或内容丢失？
iTextSharp（尤其是旧版 5.x）默认不嵌入中文字体，直接 PdfCopy 或 PdfWriter 合并会导致文字渲染失败、空白页或异常抛出。关键不是“能不能合并”，而是“是否保留源文档的字体与资源”。
- 必须显式注册支持 Unicode 的字体（如 Noto Sans CJK / simsun.ttc），并在读取每一页前调用
pdfReader.SelectPages确保页对象完整加载 - 避免使用
PdfCopy.AddPage()直接传入pdfReader.GetPageN(i)，应改用copy.AddPage(copy.GetImportedPage(reader, i)) - 若源 PDF 含 AcroForm 表单字段，
PdfCopy会丢弃字段交互逻辑；需改用PdfSmartCopy（但性能略低）
var font = BaseFont.CreateFont(@"C:\Windows\Fonts\simsun.ttc,0", BaseFont.IDENTITY_H, BaseFont.NOT_EMBEDDED);
用 PdfSharp 合并多个 PDF 时提示“Cannot access a closed Stream”？
PdfSharp 默认将整个 PDF 加载进内存流（MemoryStream），若原始文件流（如 FileStream）在 PdfDocument 构造后被提前关闭，后续调用 document.Pages.Count 或 copy.AddPage() 就会触发该异常。
- 所有输入
PdfDocument实例必须基于独立、未关闭的流，且生命周期要覆盖到最终output.Save()完成 - 不要用
using (var fs = File.OpenRead(...)) { new PdfDocument(fs); }—— 流会在 using 块结束时关闭 - 推荐方式：用
new PdfDocument(new MemoryStream(File.ReadAllBytes(path)))，或确保流对象在合并全程保持打开状态
合并含书签/目录结构的 PDF，如何保留原有层级？
原生 PdfCopy 和 PdfSharp 的基础合并都不自动继承源文档的 Outline（即书签）。若需保留，必须手动提取并重映射页码偏移。
- iTextSharp 5.x 中可遍历
pdfReader.Outlines，用copy.AddOutline()逐条重建，注意将原Destination.Page替换为新文档中的实际页码 - PdfSharp 没有内置 Outline 支持，需借助
PdfSharp.Pdf.IO.PdfReader.Open()+ 反射读取/Outlines字典（不稳定，不推荐生产环境） - 更稳妥的做法是改用 iText7：
PdfDocument+PdfMerger，它原生支持mergeOutlines = true参数
var merger = new PdfMerger(destPdf); merger.Merge(sourcePdf, new MergeOptions().SetMergeOutlines(true));
.NET 6+ 项目里该选 iText7 还是 QuestPDF？
QuestPDF 是纯生成库（从零绘制 PDF），不支持读取/修改已有 PDF；它不能用于“合并已有文件”。真正可用的只有 iText7（商业授权要求宽松，AGPL 允许内部使用）或免费替代品如 PDFtk（需命令行调用）。
- iText7 是目前最稳定的合并方案，API 清晰，支持加密、书签、图层、表单字段保留
- 注意 NuGet 包名是
iText7（不是iTextSharp），且必须同时引用iText.Kernel、iText.Layout、iText.Forms（如需表单） - 若项目不允许任何第三方许可风险，唯一可行路径是调用系统级工具：
Process.Start("pdftk.exe", "in1.pdf in2.pdf cat output out.pdf")，但依赖外部二进制且跨平台差
合并操作本身不复杂，难的是处理字体、书签、加密、XFA 表单这些隐性依赖——漏掉任意一项，用户看到的就是“看起来合并了，但点不开/打不开/缺字”。
