中文乱码主因是iTextSharp默认无中文字体，须显式加载如simhei.ttf并指定BaseFont.IDENTITY_H编码，否则显示方块或抛异常。
导出PDF时中文乱码，是因为没配中文字体
iTextSharp 默认不支持中文，直接写 document.Add(new Paragraph("你好")) 会抛出 DocumentException: Font 'Helvetica' with 'Cp1252' is not recognized. 或显示方块。核心问题不是编码设置，而是字体缺失。
必须显式注册一个支持中文的 TrueType 字体（如 simhei.ttf 或 msyh.ttc），并用 BaseFont.IDENTITY_H + BaseFont.NOT_EMBEDDED（或 EMBEDDED）加载：
var fontPath = @"C:\Windows\Fonts\simhei.ttf";
var baseFont = BaseFont.CreateFont(fontPath, BaseFont.IDENTITY_H, BaseFont.NOT_EMBEDDED);
var font = new Font(baseFont, 12);
document.Add(new Paragraph("你好，世界", font));
- 路径必须真实存在，
simhei.ttf在 Windows 系统常见，Linux/macOS 需换为系统自带中文字体路径（如/System/Library/Fonts/PingFang.ttc） - 用
BaseFont.NOT_EMBEDDED时，PDF 在无该字体的设备上可能回退为默认字体；嵌入（EMBEDDED）会让文件变大但更可控 - iTextSharp 5.x 不支持直接读取 .ttc 文件中的某一个字体子集，若用
msyh.ttc，需先用工具拆出msyh.ttf再引用
iTextSharp 5.5.13.3 导出表格内容错位或截断
表格列宽控制不靠 table.WidthPercentage = 100 就能自适应——它只缩放整个表格，不干预列内文本换行与溢出。常见现象是长文本挤在窄列里重叠，或整列被截掉。
关键要设列宽比例 + 单元格样式 + 自动换行：
var table = new PdfPTable(new float[] { 2f, 3f, 1f }); // 三列，宽度比 2:3:1
table.WidthPercentage = 100;
var cell = new PdfPCell(new Phrase("超长文本内容，应该自动换行显示", font));
cell.Padding = 5;
cell.NoWrap = false; // 必须设为 false 才换行
table.AddCell(cell);
-
NoWrap = false是硬性要求，否则即使列宽足够，文本也强行不换行导致溢出 - 列宽数组用
float[]而非整数，避免整除截断；总和无需为 100，按比例生效 - 如果某列含图片或固定高元素，需额外调
cell.MinimumHeight防止挤压
生成 PDF 后文件打不开，提示“损坏或无法读取”
最常见原因是流未正确关闭或缓冲未刷新。iTextSharp 的 Document 对象依赖底层 FileStream 或 MemoryStream 的生命周期，提前释放、重复关闭、或忘记 document.Close() 都会导致 PDF 结构不完整。
- 务必在
document.Close()之后才去读取或返回流——尤其用MemoryStream时，要先stream.Position = 0;再传递 - 不要对同一个
FileStream多次调用Close()，.NET 6+ 中using块会自动处理，但嵌套using容易误关底层流 - 若导出到 Web API（如 ASP.NET Core），别直接
return File(stream, "application/pdf")后再操作 stream；应先ToArray()或用stream.CopyToAsync(response.Body)
用 iTextSharp 5 还是升级到 iText 7？
iTextSharp 是 iText 5 的社区移植版，已停止维护；官方从 2016 年起主推 iText 7（商业授权收紧，但 AGPL 开源可用）。两者 API 差异巨大，不是简单替换命名空间的事。
如果你只是临时导出简单 PDF（如发票、报表），iTextSharp 5.5.x 仍可稳定使用；但以下情况建议直接切 iText 7：
- 需要数字签名、PDF/A 合规、表单域（AcroForm）、图层（OCG）、透明度等高级特性
- 项目已用 .NET Core/.NET 5+，iTextSharp 5 对新运行时兼容性差（如缺少
System.Drawing.Common替代方案） - 团队愿意接受学习成本：iText 7 的
Document+PdfWriter+Div/Table模型更现代，但文档分散，中文资料少
真正容易被忽略的是字体嵌入策略和流生命周期管理——这两个点出错，PDF 表面生成成功，实际打开即失败，且错误不报在生成时，而在下游消费环节才暴露。
