QuestPDF 是 C# 中生成单图 PDF 的最简可控方案，无需系统组件或 COM，以声明式布局处理图片，自动缩放居中，推荐用 byte[] 构造 ImageData 并显式设单位防失真。
用 QuestPDF 生成单图 PDF 最简路径
直接用 QuestPDF 是目前 C# 里最轻、最可控的方案，不依赖系统组件、不调 COM、不弹窗。它把 PDF 当作“布局描述”，图片就是一帧内容，写法接近 HTML + CSS 思路。
常见错误是硬套旧思路：想先画图再导出，结果卡在 Graphics 和 Metafile 上——那些方式在 .NET 6+ 中既难控尺寸，又容易 DPI 错乱、透明通道丢失。
-
QuestPDF默认按 A4（595×842 pt）渲染，图片会自动等比缩放居中；若需原始尺寸，得显式设Width/Height单位为Unit.Millimeter或Unit.Pixel - 加载本地文件用
Image.FromFile("xxx.jpg")不安全，推荐用byte[]构造：ImageData.FromBytes(File.ReadAllBytes(path))，避免文件锁和编码问题 - 中文路径或含空格路径必须用
Uri.EscapeDataString预处理，否则FromFile会静默失败
合并多图时怎么控制每页一张、不留白、不拉伸
关键不是“拼图”，而是“分页”。QuestPDF 的 Page 是独立容器，每张图塞进一个 Page 就自然分页，比手动算高度靠谱得多。
容易踩的坑是用 Column 或 Grid 把所有图堆进一页——那样只会挤成小图或溢出裁剪，根本不是“合并 PDF”。
- 循环每张图，对每个
page调用.Page(page => page.Size(PageSizes.A4).Content(...)) - 图片宽高比失真？别设固定
Width，改用.ScaleToFit()或.ScaleToWidth(500)（单位是 pt） - 首图正常、后续图变灰？检查是否复用了同一个
ImageData实例——每次都要重新从byte[]构造
iTextSharp 还能用吗？哪些场景真绕不开它
能用，但只建议用于已有老项目迁移，或必须插入文字水印、加密、数字签名等 QuestPDF 不支持的功能。新项目强行上 iTextSharp 会多踩三类坑：许可证模糊（AGPL）、.NET Core 兼容差、API 反直觉。
比如你调 document.Add(new Jpeg(...))，实际要先打开 document、再 new 图片、再 Add，漏掉 document.Open() 就静默无输出；而 QuestPDF 是声明式链式调用，错一步编译就报。
- 必须用
iTextSharp的典型场景：AcroFields填表、PdfStamper修改已有 PDF、PdfWriter设置权限密码 - 读取 PNG 透明通道？
iTextSharp默认丢 alpha，得手动提取AlphaChannel并合成，QuestPDF自动保留 - 生成速度差异不大，但
iTextSharp内存占用高约 30%，尤其处理 >10MB 图片时 GC 压力明显
导出后 PDF 打不开 / 图片模糊 / 元数据丢失怎么办
不是代码错了，大概率是输出流没关、或图片解码质量被压缩过。PDF 查看器对损坏结构容忍度低，一个字节错就直接拒载。
最容易被忽略的是：用 MemoryStream 生成 PDF 后，忘了 stream.Position = 0 就直接传给 Response.Body 或 File.WriteAllBytes——结果写入的是空文件。
- 导出前务必调
pdf.GeneratePdf()（返回byte[]），别用GeneratePdf(stream)后还去读 stream - 图片本身分辨率低？PDF 不会“超分”，
300dpi图放进 A4 页面才清晰，72dpi网图放大后必然糊 - EXIF 信息（拍摄时间、GPS）默认不带入 PDF，如需保留，得提前用
System.Drawing.Image或ImageSharp提取元数据，再用Metadata属性注入
真正麻烦的从来不是“怎么转”，而是“怎么让转出来的 PDF 在所有设备上打开都一样”。尺寸单位、DPI 解释、嵌入字体、颜色空间——这些细节藏在每行构造代码背后，改一个参数可能影响十台打印机的输出效果。
