WebView 能让你在一个窗口内嵌入完全独立的网页，这在需要展示外部内容（第三方登录页、帮助文档、在线报表）时非常方便。但由于 WebView 本质上是另一个独立的渲染进程，它的行为和普通的 BrowserWindow 或 iframe 有本质区别。实际开发中，以下几个兼容性问题最容易让开发者踩坑，而且往往在不同操作系统上表现各异。
28.2.1 预加载脚本与安全策略的差异
WebView 的 preload 脚本工作方式与普通窗口不同。在 BrowserWindow 中，preload 脚本运行在渲染进程的一个独立作用域里，可以通过 contextBridge 安全地暴露 API。但在 WebView 内，preload 脚本的运行时机和上下文可能会因为内部页面的同源策略变得更加复杂。
最典型的坑是：如果 WebView 加载的是远程内容（比如 https://example.com），而你又在 preload 脚本里使用了 Node.js 或 Electron 的原生模块，这些调用会在远程页面完全加载之前就被执行，但远程页面的 window 对象可能尚未初始化好，或者被页面自身的脚本覆盖。 更麻烦的是，如果远程服务器的 CSP（内容安全策略）头部禁止 eval 或内联脚本，即使你已经在 preload 里安全地注入了方法，页面仍然可能因为 CSP 冲突而报错。
真实解决办法很简单：始终在 WebView 上启用 contextIsolation: true 和 nodeIntegration: false，然后通过 preload 脚本用 contextBridge 暴露一个干净的对象。如果页面是远程加载的，务必在服务器端放松 CSP 策略，或者改用 webview 的 executeJavaScript 方法在页面就绪后注入逻辑，而不是依赖 preload。
28.2.2 导航与跳转的白屏问题
WebView 内部页面的导航行为不像浏览器标签页那样有直观的进度条和回退按钮。一旦页面内部发生了 window.location 跳转或用户点击了 target="_blank" 的链接，你有很大概率遇到两种白屏：
- 跳转到新窗口被阻止：默认情况下，WebView 会拦截新窗口的创建并触发
new-window事件。如果你没有显式处理这个事件并允许它在系统浏览器中打开，WebView 会直接吞掉这次跳转，页面看起来就像点击后什么也没发生。 - 加载中断无反馈：如果目标 URL 响应了一个下载文件（比如 PDF 或 ZIP），WebView 默认无法处理下载。它只会呆在原地不动，用户会以为应用卡死了。
处理方式就是在创建 WebView 时监听 did-navigate、will-navigate 和 new-window 事件，根据 URL 的类型决定是在 WebView 内继续导航，还是交给系统浏览器（shell.openExternal）。对于可能的下载请求，还要监听 will-download 事件来手动触发保存对话框。
28.2.3 跨平台渲染和输入差异
WebView 内部渲染使用的是与主程序相同的 Chromium 引擎，但不同操作系统上的字体渲染、输入法行为、甚至默认的滚动条样式都会导致视觉和交互不一致。
- 字体：Windows 和 macOS 的中文字体回退机制完全不同，如果不显式指定字体栈，同一个页面在 WebView 中可能会出现字体大小、行高明显差异，甚至中文字符变成方框。
- 输入法：在 WebView 中，输入法的候选框位置经常错位，尤其是在 WebView 被放置在一个带滚动条或
transform定位的容器中时。这是 Chromium 内部坐标计算的老问题，目前没有完美的通用修复，只能通过调整页面布局减少嵌套定位。 - 右键菜单：默认情况下，WebView 的右键菜单是 Chrome 的原生上下文菜单，包含“检查元素”、“重新加载”等对最终用户来说意义不明的选项。如果不手动调用
webview.addEventListener('context-menu', ...)并阻止默认行为，然后弹出自定义菜单，用户就会看到这些调试选项，显得应用很不专业。
28.2.4 内存与性能陷阱
每个 WebView 都会启动一个独立的渲染进程，占用独立的内存空间。如果你的应用在主窗口之外还开启了多个 WebView（比如一个复杂的仪表盘嵌入了三个不同域名的内嵌页面），内存会成倍增长。更糟糕的是，WebView 的进程不会随着 WebView 元素的隐藏或移除而立刻被回收。如果你动态创建和销毁 WebView，需要显式调用它的 destroy() 方法，并确保 DOM 元素已经从页面中移除，否则这些“僵尸进程”会一直常驻内存，直到主窗口关闭。
另外，WebView 的页面加载不一定比 iframe 快。有些开发者错误地认为 WebView 因为是独立进程，所以性能一定更好。但实际上，WebView 的初始化成本（启动独立渲染进程、加载 preload 脚本）比插入一个 iframe 要高得多。对于简单、可信的嵌入内容，如果不需要独立的进程隔离，用 iframe 反而是更轻量的选择。
28.2.5 与主进程通信的延迟和死锁
WebView 与主进程之间的消息传递必须经过 webview.send() 和 ipcRenderer 的中转。如果这一来一回的处理逻辑没有做好错误捕获，很容易出现“点了按钮没反应，过几秒才弹框”的体验。更隐蔽的坑是，如果主进程在处理 WebView 发来的请求时又反过来调用 WebView 的 executeJavaScript，而 WebView 恰好在页面卸载或导航过程中，这个调用可能会被挂起，导致整个通信链死锁。
最佳实践是单向通信优先：尽量用 webview.send() 向主进程发通知，然后让主进程通过独立的 IPC 通道（比如一个主窗口的渲染进程）来更新 UI，而不是直接在 WebView 上执行 JavaScript 回调。如果必须在 WebView 内执行代码，一定要用 webview.isLoading() 或 dom-ready 事件做前提确认。
总结来说，WebView 是用强大能力换取了这些“坑”的组件。你之所以要使用它，为的是进程隔离、独立的安全上下文和完整的网页渲染能力。但只要在实际开发中把上面这五类问题预先考虑到，并在代码中加上相应的守卫逻辑和平台测试，绝大多数兼容性难题都能避免。记住一个实用原则：能用 iframe 的简单场景就不要上 WebView，用了 WebView 就一定要为导航、内存和 preload 安全做好预案。