应优先使用 OpenXML SDK 解析 Word 图片，因其稳定可控且不依赖 Office；需遍历 ImagePart 集合获取原始字节并校验文件头判断真实格式，避免误信文件名或 UI 显示。
用 Microsoft.Office.Interop.Word 读取 Word 图片会卡死或报错
直接调用 COM 接口读图，本质是启动隐藏的 Word 进程，对服务器环境不友好，且容易在无桌面会话时崩溃（比如 Windows Server 的 IIS 应用池里）。常见错误是 COMException: 拒绝访问 或进程残留导致后续调用卡住。
- 只在 Windows 桌面应用中考虑它，Web 后端、Linux、Docker 环境一律绕开
- 必须手动释放
Document和Application对象，否则 Word 进程不退出：doc.Close(false)+app.Quit()+Marshal.ReleaseComObject() - 图片实际以
InlineShape或Shape形式存在，需遍历两者，不能只查一个
用 DocX（Novacode）提取图片失败：返回空或路径无效
DocX 是纯托管库，不依赖 Office 安装，但只支持 .docx（不支持 .doc），且图片提取逻辑有陷阱：它把图片存为内嵌关系 ID，不是直接二进制流，Picture 对象的 ImageData 属性可能为 null，尤其当图片来自复制粘贴或经过格式转换后。
- 确认文件扩展名是
.docx，且未被另存为“兼容模式”（另存为时勾选了“保持与旧版本兼容”会降级为 .doc 格式） - 用
document.Images获取所有图片对象后，必须通过image.GetPictureBytes()提取原始字节，不能直接读image.ImageData - 提取出的字节需自行判断格式（
JPEG/PNG头），再保存为对应后缀文件，否则可能打不开
用 OpenXML SDK 解析图片时找不到 ImagePart
OpenXML 是最稳定可控的方式，但图片不在主文档 XML 里，而分散在 word/media/ 子包中，靠 Relationship 关联。如果只查 document.MainDocumentPart 而忽略 ImagePart 集合，就会漏掉所有图。
- 必须打开
WordprocessingDocument并获取MainDocumentPart，再遍历其所有GetPartsOfType() - 每个
ImagePart的Uri是相对路径（如/word/media/image1.png），内容需用ImagePart.GetStream()读取 - 注意：有些图片可能是 WMF/EMF 格式（尤其从 Excel 或旧版 Word 插入），
System.Drawing.Common在 .NET Core/.NET 5+ 上默认不支持，需额外处理或跳过
提取的图片模糊、尺寸异常或带水印
Word 文档里的图片常被压缩或缩略显示——你在 UI 里看到的图，未必是原始图。原图可能被裁剪、重采样，甚至只是高斯模糊后的占位图（尤其从网页复制进来的图）。
- 优先检查
ImagePart的原始字节是否完整：用十六进制查看前几个字节，确认是FF D8 FF（JPEG）或89 50 4E 47（PNG） - 若字节正常但显示模糊，大概率是 Word 自动压缩所致；原始图已不可逆丢失，只能接受或提醒用户插入未压缩图
- 某些企业模板会在图片上叠透明水印层（作为
Shape叠加在InlineShape上），此时需同步提取Shape中的blipFill引用，而非只盯InlineShape
事情说清了就结束。真正难的不是“怎么拿到图”，而是判断“这图是不是原图”。别信 UI 显示，得看字节头；也别信文件名，image2.jpeg 可能是 PNG 数据。
