windows自带webbrowser控件无法渲染pdf，因其依赖已禁用的ie pdf插件；推荐使用webview2配合pdf.js，需安装运行时、启用corewebview2并避免file://协议。
用 WebBrowser 控件加载本地 PDF 文件行不通？
Windows 自带的 WebBrowser 控件在 WinForm 中无法直接渲染 PDF——它依赖 IE 内核，而 IE 从 Windows 10 开始默认禁用 PDF 插件，且微软已彻底移除对 PDF 的 ActiveX 支持。你看到空白、报错 NavigationCanceled 或弹出“无法显示此网页”，都是这个原因。
实操建议：
- 别再尝试注册
AcroPDF.PDF或PDF.PdfCtrl这类旧 COM 组件，它们在 64 位系统、新 Acrobat 版本或无 Adobe Reader 的机器上大概率失败 - 避免用
WebBrowser.Navigate("file://...")直接打开 .pdf 路径，即使本地能跑，部署到客户机时几乎必挂 - 如果必须用轻量方案，改走
WebView2（需安装运行时），它基于 Edge Chromium，原生支持 PDF 渲染
WebView2 加载 PDF 的最小可行配置
WebView2 是目前 WinForm 嵌入 PDF 最稳定的选择，但不是装完 NuGet 就能用。核心问题是：它默认不启用 PDF MIME 类型处理，且本地文件协议受限。
实操建议：
- 安装
Microsoft.Web.WebView2NuGet 包（推荐 1.0.2420.45+） - 初始化时必须调用
EnsureCoreWebView2Async()，否则Source赋值无效 - 不能直接用
file://协议加载 PDF：改用https://服务（如内建HttpListener）或转为data:URI（仅适合小文件） - 示例关键代码：
await webView21.EnsureCoreWebView2Async(); webView21.Source = new Uri("https://localhost:8080/doc.pdf"); // 需自行起一个极简 HTTP 服务
为什么不用第三方 PDF 库（如 PDFiumSharp 或 QuestPDF）？
这些库擅长生成 PDF，但不提供 UI 渲染控件。想“显示 PDF”，你得自己搭画布、解析流、逐页绘制——工作量接近重写阅读器。真这么干，不如直接上 PDFium.NET SDK 或 LEADTOOLS 这类商业组件。
实操建议：
-
PDFiumSharp只暴露解析 API，没RenderToBitmap()或DrawPage()方法，WinForm 里没法直接贴图 -
iTextSharp和QuestPDF定位是“写 PDF”，强行读取+渲染会踩内存泄漏、字体缺失、表单交互丢失等坑 - 开源替代中，
PDF.js+WebView2是更现实的组合：把 PDF.js 打包进资源，用WebView2加载本地 HTML 页面，由 JS 渲染 PDF
部署时最常被忽略的兼容性点
开发机跑通 ≠ 客户机能用。WebView2 的运行时依赖、PDF.js 的跨域策略、证书验证都会在实际环境中突然失效。
实操建议：
- 必须检查目标机器是否安装 WebView2 Runtime（推荐用
EvergreenBootstrapper方式分发，而非假设用户有 Edge） - 若用内建 HTTP 服务提供 PDF，记得关闭 SSL 验证（
webView21.CoreWebView2.Settings.AreDefaultScriptDialogsEnabled = true;不够，还要处理WebResourceRequested事件拦截证书错误） - PDF 文件路径含中文或空格？
Uri.EscapeDataString()处理后再拼 URL，否则 404 - 首次加载慢？PDF.js 默认懒加载，加
?disableWorker=true参数可绕过 Worker 初始化失败问题
PDF 渲染不是“找个控件拖进去”就能搞定的事，真正卡住人的永远是环境适配和静默失败——比如 WebView2 启动超时却不抛异常，或者 PDF.js 报 Failed to load PDF file 却没告诉你是因为 CORS 拦截了字体请求。
