Windows下C#无通用文件预览能力，需按类型选择方案：PDF用WebView2+pdf.js，Office文档宜转PDF后复用，简单格式需注意解码、异步与安全校验。
Windows 平台下，C# 本身不提供通用文件预览能力——WebBrowser 控件只能渲染 HTML/HTM，Windows Forms 和 WPF 均无内置 PDF/Word/Excel 预览组件。真正能落地的方案取决于文件类型和宿主环境，不是“写个函数就能预览”。
用 System.Diagnostics.Process.Start 调用系统默认程序最简单但有局限
这是最快上手的方式，适用于开发内部工具、对体验要求不高的场景。本质是让 Windows 用关联程序打开文件（比如用 Adobe Reader 打开 PDF，用 Word 打开 DOCX）。
常见错误现象：Process.Start("test.pdf") 在无 PDF 关联程序的机器上报错；调试时路径含空格导致启动失败；文件被独占锁定时静默失败。
- 必须传入绝对路径：
Process.Start(@"C:\temp\report.pdf")，相对路径容易失败 - 建议加异常捕获：
try { Process.Start(filePath); } catch (Win32Exception ex) when (ex.NativeErrorCode == 1155) { /* 无关联程序 */ } - 无法嵌入到窗体中——它会弹出独立窗口，不能作为 UI 一部分
- 不适用于服务端或无桌面会话的环境（如 Windows Server 无交互会话时直接抛异常）
PDF 预览用 WebView2 加 pdf.js 是目前最可控的方案
WebView2 可内嵌浏览器引擎，配合 Mozilla 开源的 pdf.js，能纯前端渲染 PDF，不依赖本地软件，且支持缩放、翻页、文本选择。
使用前提：项目需引用 Microsoft.Web.WebView2 NuGet 包（v1.0.2298+），目标框架 ≥ .NET 6，且用户机器已安装 Edge WebView2 运行时（可随应用部署）。
- 把
pdf.js解压后放入项目Resources\pdfjs\目录，设Copy to Output Directory = Copy always - 加载方式：
webView.CoreWebView2.Navigate($"file:///{Path.GetFullPath("Resources/pdfjs/web/viewer.html")}?file=../{Uri.EscapeDataString(Path.GetFileName(filePath))}"); - 注意路径拼接安全：不能直接拼接用户传入的
filePath，需校验是否在允许目录内，否则存在路径遍历风险 - 首次加载较慢（约 1–2 秒），可预热
CoreWebView2或显示 loading 提示
Office 文档（DOCX/XLSX）用 Microsoft.Office.Interop 风险高，推荐转 PDF 后复用上一方案
Interop 方案看似直接，但实际问题密集：必须本机装对应版本 Office；多线程调用极易崩溃；COM 对象释放稍有遗漏就会内存泄漏；UAC 权限不足时静默失败；Server 环境严禁使用（微软官方明确不支持）。
更稳妥的做法是用开源库先转成 PDF，再交给 WebView2 + pdf.js 渲染：
-
DocX（仅 DOCX）、NPOI（DOCX/XLSX/PPTX）可读取内容，但不支持完整排版渲染 -
LibreOffice SDK或命令行调用soffice --headless --convert-to pdf更可靠，但需部署 LibreOffice - 商业方案如
Aspose.Words支持高质量 DOCX→PDF 转换，无外部依赖，但需授权
关键点：转换过程是 CPU 密集型操作，务必异步执行并设超时（例如 30 秒），避免界面卡死或 DoS。
图片/文本等简单格式直接用 PictureBox 或 TextBox 加载即可，但要注意边界
这类格式看似简单，实则容易忽略细节：
-
PictureBox.Load()不支持 WebP、AVIF 等新格式（.NET 6+ 才开始逐步支持），遇到未知格式会抛OutOfMemoryException（命名误导，实为解码失败） - 大图（如 100MB TIFF）直接
Load()会导致 UI 线程长时间阻塞，应改用Task.Run(() => Image.FromFile(...))异步加载 - 文本文件需判断编码：
File.ReadAllText(path, Encoding.Default)在中文系统下常误判为 GBK，推荐用Ude库自动检测，或优先尝试 UTF-8 + BOM - 不验证文件头就按扩展名加载，可能被恶意构造的文件触发异常（如把 EXE 改名为 JPG）
文件预览真正的复杂点不在“怎么显示”，而在“谁来负责解码、权限怎么控、失败了如何降级、资源怎么清理”。一个健壮的预览模块，往往 70% 代码都在处理路径校验、异常分支、内存释放和超时控制——而不是写 Load() 那一行。
