导出PDF不必须用iTextSharp；推荐iText7（MIT许可）、QuestPDF或PdfSharpCore。iText7需显式注册中文字体、避免路径依赖、正确管理流和关闭文档。
导出PDF必须用iTextSharp吗？先看替代方案
不必须。iTextSharp 是 .NET 早期最常用的 PDF 生成库，但自 2016 年起官方已停止维护（iTextSharp 5.x），且其许可证在商业项目中存在风险（AGPL）。现在更稳妥的选择是：iText7（官方支持、MIT 许可的免费社区版可用）或轻量级替代如 QuestPDF、PdfSharpCore（纯 C#、无原生依赖）。如果你正在维护老项目且用的是 iTextSharp 5.5.13.2 等旧版，升级前务必确认许可证合规性。
iText7 生成电子发票的关键步骤
生成带表格、中文、页眉页脚的电子发票，核心不是“怎么写代码”，而是“怎么避开字体和编码坑”。iText7 默认不支持中文，直接写汉字会显示为空白或方框。
- 必须显式注册支持 GBK/UTF-8 的中文字体（如
simhei.ttf或msyh.ttc），不能依赖系统字体路径——部署到 Linux 服务器时路径不存在 -
PdfFontFactory.Register只注册一次，推荐放在应用启动时（如Program.cs中），而非每次导出都调用 - 表格单元格内容要用
new Cell().Add(new Paragraph("金额：").SetFont(font))，不能直接传字符串 - 页码需用
Document.AddEventHandler(PdfDocumentEvent.END_PAGE, new HeaderFooterHandler())自定义事件，不能靠document.ShowTextAligned硬写位置
常见报错：中文乱码、空PDF、System.NotSupportedException
这些错误基本都指向同一个根源：字体未加载成功或 PDF 写入流被提前关闭。
-
System.NullReferenceException: Object reference not set to instance of an object→ 多因PdfFont对象为null，检查PdfFontFactory.CreateFont(...)是否抛异常（文件路径错、字体损坏、权限不足） - 生成的 PDF 打开是空白页 → 检查是否漏掉
document.Close()，或PdfWriter构造时用了MemoryStream但未设置.Position = 0就返回给前端 - 金额列数字右对齐但中文左对齐失效 → 表格单元格默认
TextAlignment.LEFT，需对每个Cell单独设SetTextAlignment(TextAlignment.RIGHT)
一个最小可运行的发票导出示例（iText7 + 中文字体）
以下代码片段能直接跑通，重点在字体加载与流管理：
var fontPath = Path.Combine(AppContext.BaseDirectory, "fonts", "simhei.ttf");
var font = PdfFontFactory.CreateFont(fontPath, PdfEncodings.IDENTITY_H, true);
using var writer = new PdfWriter("invoice.pdf");
using var pdf = new PdfDocument(writer);
using var document = new Document(pdf);
document.Add(new Paragraph("电子发票").SetFont(font).SetFontSize(16));
var table = new Table(UnitValue.CreatePercentArray(new float[] { 1, 1, 1 })).UseAllAvailableWidth();
table.AddCell(new Cell().Add(new Paragraph("商品").SetFont(font)));
table.AddCell(new Cell().Add(new Paragraph("数量").SetFont(font)));
table.AddCell(new Cell().Add(new Paragraph("金额").SetFont(font)));
document.Add(table);
document.Close(); // 必须调用
注意：simhei.ttf 要真实存在于输出目录的 fonts/ 子目录下；如果用 Web API 返回 PDF，记得把 MemoryStream 的 Position 设为 0，并设 Content-Type: application/pdf。
字体兼容性比想象中脆弱——同一份代码在 Windows 上正常，在 Alpine Linux 容器里可能因缺少字体解析库而崩溃。真要上生产，建议把字体文件嵌入程序集并用 Assembly.GetExecutingAssembly().GetManifestResourceStream(...) 加载，而不是依赖文件系统路径。
