企业官网建设流程全解析

简介：这是一份面向VC++/Win32开发者的WebView2集成示例资料包，旨在帮助在Windows桌面应用中嵌入基于Chromium的Edge浏览器内核，实现现代、快速、安全的网页浏览体验。资源包共448个文件，大小约35.99MB，涵盖C++头文件与源工程、C#示例、HTML/XAML前端页面、MD说明文档以及DLL动态库等，类型覆盖从初始化环境、页面导航到JS交互和权限管理的完整示例代码。已有282人学习下载，适合有一定Windows应用开发基础、希望快速上手WebView2的开发者。通过剖析其中示例，读者可以掌握WebView2环境的创建、Navigate导航控制、ExecuteScript注入、WebResourceRequested请求拦截等关键接口，并借助Edge DevTools调试和版本更新机制，为现有应用增添Chromium内核的现代浏览能力。

1. 为什么 VC++ 界面里要换 Edge 内核：从 WebBrowser 控件到 WebView2 的必然切换

接手一个用 MFC 维护了十几年的老桌面系统，业务方突然要求把统计图表换成 HTML5 大屏，还要在界面里直接播放 H.265 监控视频。老的 WebBrowser 控件实际上是 IE 内核，CSS Grid 不支持、ES6 跑不动、视频硬解更是空谈。VC++ 界面里要换 Edge 内核，最现实的手段不是去调用一个叫“Edge 控件”的东西，而是接入 WebView2——它正是基于 Chromium 内核的嵌入式运行时。这篇文章按照选型、初始化、避坑、进阶的顺序，把从零接入手写一遍，适合正在维护 MFC/Win32 应用、又不想把整套 UI 重写的团队。

2. WebView2 选型与初始化：固定版本还是自动版本，环境依赖怎么搭

2.1 先分清：WebView2 不是“把 Edge 嵌进 MFC”，而是“复用 Edge 内核”

很多人第一次接触，会以为 WebView2 是把完整浏览器塞进窗口里，就像嵌入一个 iframe 那么简单。实际上，WebView2 的架构更像是一个“主机进程 + 渲染进程”的组合。你的 VC++ 程序是宿主，调用ICoreWebView2Controller把一个原生窗口句柄交给运行时的渲染进程，Edge 内核的渲染结果直接绘制到这个 HWND 上。它没有一个固定可见的浏览器外壳，地址栏、菜单、下载列表都不在，除非你自己实现。

所以你在 VC++ 界面里使用 Edge 浏览器内核，本质上做的是三件事：创建控制器、把控制器绑定到窗口、然后通过ICoreWebView2接口控制导航和脚本交互。这个思路和我之前做嵌入式 Chrome 的方案完全不同，WebView2 不需要自行分发几百 MB 的浏览器安装包，安装包由微软的 WebView2 Runtime 统一管理，你的程序只负责调用 API。

也正因为如此，WebView2 并不是“IE 控件的升级版”。IE 的 WebBrowser 控件是 ActiveX 文档对象，很多接口是在文档树上直接操作；WebView2 则是一个完整的 Chromium 实例，接口风格更接近自动化测试里的 CDP 协议。初次从CWebBrowser2迁移过来，最大的障碍反而是事件模型变了——原来DocumentComplete、NavigateError这种 COM 事件，现在变成NavigationStarting、NavigationCompleted、WebMessageReceived这类异步回调。

2.2 Evergreen 与 Fixed Version：离线工控机上的“后悔药”

选型第一件事是决定用 Evergreen Runtime 还是 Fixed Version Runtime。Evergreen 模式是默认的，程序启动时加载系统里已经安装的 WebView2 Runtime，由系统自动更新。好处是不用操心浏览器内核安全更新，前提是目标机器必须能装 Runtime、能联网更新。对于办公软件、内部管理系统，这个模式问题不大，装一次 Runtime 就能持续跑。

Fixed Version 模式则是把指定版本的 Runtime 文件直接放在你的程序目录或者子目录里，程序通过环境变量或注册表指向这个目录。它的最大价值在离线环境：产线设备、军工内网、医院机房，很多机器不允许安装在线更新组件，甚至不允许写注册表。这时候固定版本就是你最后的“后悔药”——哪怕外面的 Runtime 更新到天翻地覆，你程序用的内核还是当时验证过的那一版。

两个模式的取舍，我的建议非常实际：应用面向公网普通用户，用 Evergreen，省去版本维护；面向企业内网、工控、长期离线设备，用 Fixed Version。还有一种混合场景：开发机装 Evergreen，交付机用 Fixed Version，代码里通过环境变量切换，调试和交付互不影响。部署时注意一个细节：Fixed Version Runtime 是以浏览器内核组件的形式存在的，不是一个简单的 DLL，你需要把整个msedgewebview2.exe所在的目录结构带上，不是只拷一个文件。

2.3 初始化前检查三件事：VC++ 运行库、WebView2 Runtime、32/64 位匹配

我见过的翻车现场，十有八九不是 API 写错，而是环境问题。初始化 WebView2 之前，先确认三件事。

第一，VC++ 运行库。WebView2 的 C++ API 依赖WebView2Loader.dll，如果你用 Visual Studio 开发，项目里链接的是WebView2Loader.lib，这个 loader 会动态加载运行时。注意你的目标平台：不能在一个 x86 的 EXE 里加载 x64 的WebView2Loader.dll，反之亦然。实际分发时很多团队直接把WebView2Loader.dll拷到 exe 目录，省去在系统目录注册的麻烦，这是常见做法，但要保证位数一致。

第二，WebView2 Runtime 是否安装、版本够不够。可以查注册表，也可以直接看C:\Program Files (x86)\Microsoft\EdgeWebView\Application下是否存在版本号目录。注意浏览器内核组件的安装路径也在这里，别把 Edge 浏览器目录和 WebView2 Runtime 目录混淆。手动检查代码里我一般这样写：

Get-ChildItem "HKLM:\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients\*" | Where-Object { $_.GetValue("name") -match "WebView" } | Select-Object -ExpandProperty PSChildName

这段 PowerShell 脚本检查的是 64 位系统上 32 位视角下的 EdgeUpdate 注册表项。Clients下的子键代表安装了哪些基于 Chromium 的产品，WebView2 Runtime 会有一个固定的 GUID 或者包含WebView的name字段。PSChildName是子键名，对应的pv值就是版本号。这个命令只是为了确认运行时存在，不依赖版本就返回-match "WebView"的所有条目。

第三，位数匹配。这里特别容易踩坑：如果你的 VC++ 程序是 32 位编译，那么加载的 WebView2 Runtime 也必须支持 32 位进程。实际上 WebView2 Runtime 安装包会把 32 位和 64 位都装到系统里，但如果你在程序里通过环境变量强制指定了一个 64 位的 Fixed Version 目录，32 位程序可能直接报“尝试加载格式不正确”的异常。检查方法是在初始化后调用GetAvailableCoreWebView2BrowserVersionString，看一下返回的版本字符串和进程位数；也可以直接看任务管理器里的msedgewebview2.exe是否带(32 位)。

3. 在 MFC 对话框里嵌入 Edge 内核：最小可运行工程与双向通信

3.1 创建环境并绑定窗口句柄：CreateCoreWebView2EnvironmentWithOptions 的正确用法

MFC 对话框里嵌 WebView2，核心步骤是先创建一个环境对象，再基于环境创建控制器。环境对象负责管理用户数据目录、语言、版本策略；控制器负责把渲染内容绑定到具体 HWND。这里有一个关键认知：绑定的是 HWND 本身，不是某个控件 ID。也就是说，你可以在你的对话框里放一个Picture Control、静态文本或者自定义CStatic子类，把它当作渲染容器，然后把它的 HWND 传给控制器。容器类本身不需要具备任何特殊能力，它只是占位。

最小可用的初始化代码，我一般放在对话框的OnInitDialog子类重载里，但注意不要阻塞 UI 线程。因为创建过程是异步的，回调会在线程池上触发。具体代码如下：

#include <webview2.h> // 假设 m_webviewHwnd 是容器窗口句柄 // m_webviewController 是成员变量 CComPtr CoInitializeEx(nullptr, COINIT_APARTMENTTHREADED); CComPtr<ICoreWebView2Environment> spEnv; HRESULT hr = CreateCoreWebView2EnvironmentWithOptions( nullptr, // browserExecutableFolder，nullptr 表示用系统安装的 Evergreen L"D:\\MyApp\\WebView2Data", // userDataFolder，浏览器缓存与配置文件目录 nullptr, // options，固定版本可用 CoreWebView2EnvironmentOptions Callback<ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler>( [this](HRESULT result, ICoreWebView2Environment* env) { if (FAILED(result)) { return result; } env->CreateCoreWebView2Controller( m_webviewHwnd, Callback<ICoreWebView2CreateCoreWebView2ControllerCompletedHandler>( [this](HRESULT result, ICoreWebView2Controller* controller) { if (FAILED(result)) { return result; } m_webviewController = controller; controller->get_CoreWebView2(&m_webviewCore); return S_OK; }).Get()); return S_OK; }).Get());

这段代码是典型的 WebView2 异步两级回调。CreateCoreWebView2EnvironmentWithOptions的第一个参数browserExecutableFolder是关键：传nullptr，走的是系统全局 Evergreen Runtime；如果传了 Fixed Version Runtime 的目录，则完全从该目录启动，不再理会系统版本。第二个参数userDataFolder决定 Cookie、LocalStorage、IndexedDB 落在哪，交给一个独立目录是必须的，我一般会放在用户 AppData 下，避免写在程序安装目录导致权限问题。第三个参数options用来设置语言、排除指定版本或者自定义开关，普通场景传nullptr即可。

还有一句提醒：这段代码里用了Callback<>模板，它是webview2.h头文件里提供的简化回调辅助类，比手搓 COM 接口快得多。MFC 工程里注意把它放在InitInstance里调用CoInitializeEx，不要放在OnInitDialog里，否则可能因为 COM 线程模型冲突导致重入问题。

3.2 导航、事件回调与窗口尺寸：NavigationCompleted 之后再显示，避免白屏

控制器创建成功后，接口还不够用。要让它显示内容并响应导航，你需要拿到ICoreWebView2接口，也就是前面代码里的m_webviewCore。我一般在控制器回调里紧接着做三件初始化：设置背景色、注册导航完成事件、导航到初始页。

先看导航和尺寸设置：

RECT rcClient; GetClientRect(m_webviewHwnd, &rcClient); m_webviewController->put_Bounds(rcClient); // 设置渲染区域 m_webviewController->put_IsVisible(TRUE); // 默认已经可见，但显式写出来更稳妥 m_webviewCore->add_NavigationCompleted( Callback<ICoreWebView2NavigationCompletedEventHandler>( [this](ICoreWebView2* sender, ICoreWebView2NavigationCompletedEventArgs* args) { BOOL isSuccess = FALSE; args->get_IsSuccess(&isSuccess); if (isSuccess) { // 导航成功后再把外部窗口显示出来 // 这里用 PostMessage 通知 UI 线程，不要在回调线程里直接操作窗口 } return S_OK; }).Get());

put_Bounds接受一个RECT，控制器会把网页渲染到这块矩形范围里。这个矩形对应的是容器窗口在整个屏幕上的位置；如果容器在对话框中移动了，需要手动更新。很多初学者把put_Bounds写在创建控制器之前，那是拿不到ICoreWebView2Controller的，必然报空指针。正确顺序永远是：先创建控制器，再设置边界。

add_NavigationCompleted是判断页面是否真正加载完成的最直接途径。这里有一个“白屏”的经典操作：不要在回调线程里直接SetWindowPos或者ShowWindow，因为 WebView2 的事件回调线程和 MFC 的 UI 线程不是同一个。正确做法是PostMessage到主窗口，由OnMessageHandler去显示。如果直接操作窗口，轻则闪烁，重则死锁。这也是为什么官方示例里大量使用Callback配合消息泵的原因。

页面加载成功后，窗口尺寸变化时要重设 Bounds。MFC 里处理WM_SIZE：

void CMyDialog::OnSize(UINT nType, int cx, int cy) { CDialogEx::OnSize(nType, cx, cy); if (m_webviewController) { RECT rc{ 0, 0, cx, cy }; m_webviewController->put_Bounds(rc); } }

如果不做这一步，对话框拉大后浏览器内容只显示原来的区域，剩下部分变成残留残影。我习惯把put_Bounds放到OnSize和保护 m_webviewHwnd 的非空判断里，否则对话框初始化阶段触发WM_SIZE时会访问空对象。

3.3 C++ 与 JavaScript 双向通信：PostWebMessageAsJson 与 WebMessageReceived 的配对写法

大多数界面换 Edge 内核的项目，不只是显示静态网页，更核心的是页面和 MFC 原生代码交换数据。WebView2 提供了一条干净的双向消息通道：C++ 通过PostWebMessageAsJson向网页发消息，网页通过window.chrome.webview.postMessage向 C++ 发消息。

先看 C++ 侧接收网页消息：

m_webviewCore->add_WebMessageReceived( Callback<ICoreWebView2WebMessageReceivedEventHandler>( [this](ICoreWebView2* sender, ICoreWebView2WebMessageReceivedEventArgs* args) { LPWSTR message = nullptr; args->get_WebMessageAsJson(&message); // message 是 JSON 字符串，可以解析出业务数据 // 注意：这个线程不是 UI 线程，解析完数据要 PostMessage 到 UI 线程 CoTaskMemFree(message); return S_OK; }).Get());

网页侧发送只需要一行 JavaScript：

window.chrome.webview.postMessage({ cmd: 'getData', id: 1001 });

反过来，C++ 往网页发送数据：

m_webviewCore->PostWebMessageAsJson(L"{\"type\":\"status\",\"value\":\"ok\"}");

网页侧监听：

window.chrome.webview.addEventListener('message', arg => { console.log(arg.data); });

这里有个细节很少有人强调：get_WebMessageAsJson返回的是 COM 分配的字符串，用完必须CoTaskMemFree，否则每个消息泄漏一小块内存。这类内存泄漏平时看不出来，跑一整天后任务管理器里内存暴涨，还找不大到出处，属于典型的“血泪经验”。

配对使用这套接口时，协议设计就变得很重要。常见的做法是约定一个 JSON 信封，比如{action: "getData", requestId: 3}，然后 C++ 侧按action分发方法，返回结果时带上同一个requestId，这样页面可以关联请求和响应。消息大小也要限制，超过几 MB 的大对象直接传文本会卡顿，建议传文件路径或者索引，C++ 侧再读文件。另外，消息通道是异步的，不要指望页面立即返回结果，MFC 里要设计好等待机制。

4. WebView2 实战避坑：闪屏、进程残留与版本错乱的排查记录

4.1 现象一：Debug 版一拖入控件就崩溃，Release 却正常

明明同一个工程文件，Debug 编译运行到创建控制器直接崩，Release 好端端。崩溃点在CreateCoreWebView2EnvironmentWithOptions，错误堆栈指向WebView2Loader.dll。

原因是在 Visual Studio 工程里，WebView2Loader.lib默认只链接了 Release 版本的导入库，而 Debug 配置没有把WebView2Loader.lib的路径加进链接器输入。更常见的情况是，Debug 运行时CString、shared_ptr的 ABI 和 Release 版本不一致，但崩溃只发生在 WebView2Loader 里，实际是 DLL 版本没对应上。

解决方式：到项目配置里，确认“链接器 -> 输入 -> 附加依赖项”在 Debug 和 Release 两个配置里都包含同一个WebView2Loader.lib；如果用的是 NuGet 包管理方式，检查包是否对Debug配置生成了单独的库目录。我还见过一种情况：Debug 启动时编译器把_ITERATOR_DEBUG_LEVEL设置得和 WebView2 头文件不匹配，导致Callback<>模板实例化出错。这种情况确实属于 Debug/Release 配置不一致，最终统一了运行库类型v141/v142/v143就解决了。

4.2 现象二：首次导航窗口白屏 3 秒，然后内容才弹出来

程序启动后对话框先是一片白，过两三秒网页才刷出来。这个问题几乎每个项目都会遇到，因为你看到的是“网页渲染完成前，容器窗口背景色”的颜色。WebView2 控制器默认背景色是白色，在网页加载完成前，渲染区域完全被白色覆盖。

解决有两个方向：一是把m_webviewHwnd的背景包成灰色或黑色，让白屏不那么刺眼；更彻底的是在创建控制器后立刻设置背景色，然后用AddScriptToExecuteOnDocumentCreated注入一个最小样式把背景改成需要的颜色。我常用的做法是把整个嵌入过程放在后台线程里执行，控制器创建完成后才显示对话框，也就是前面提到的“NavigationCompleted 之后再显示”的思路。还有一个不可忽略的点：不要在一个窗口还没有OnShowWindow完成的时机里立刻导航，Windows 的消息循环会被阻塞，渲染进程虽然在工作，但窗口没有刷新，表现出来也是一个白块。

4.3 现象三：关闭对话框后 msedgewebview2.exe 还赖在任务管理器

点掉对话框后，进程列表里多了好几个msedgewebview2.exe，关不掉。这是 WebView2 最常见的进程残留问题。原因是控制器对象虽然释放了，但浏览器进程还在运行，需要调用Close方法显式通知它退出。

正确清理代码：

if (m_webviewController) { m_webviewController->Close(); m_webviewController.Release(); } if (m_webviewCore) { m_webviewCore.Release(); }

注意顺序：先Close控制器，再释放ICoreWebView2引用。如果只Release不Close，浏览器进程会继续等待宿主接口的引用计数归零，但它不知道宿主窗口已经销毁。还有一种情况是主程序直接退出，没有调用PostQuitMessage循环，导致 COM 回调线程仍然挂起。解决方法是OnDestroy里先Close，再调用CoUninitialize。

如果多实例场景下残留更明显，你还需要给每个 WebView2 指定独立的userDataFolder，否则一个进程崩溃可能导致所有实例崩溃。这个坑虽然不直接造成进程残留，但会放大问题，排查起来非常头疼。

4.4 现象四：H.265 视频有声音没画面，页面提示需要扩展

监控厂商提供的网页播放器多是 H.265 编码，直接塞到 WebView2 里出现有声音没画面。原因不是 WebView2 不支持 H.265，而是 Chromium 默认的硬解能力依赖系统媒体框架，Windows 10 上需要装“来自设备制造商的 HEVC 视频扩展”，这个组件不少系统默认没有。

解决分两条路。一是给目标机器安装 HEVC 视频扩展，这是最直接的，但内网分发麻烦；二是建议厂商在 Web 端转码成 H.264，或者使用支持 WASM 软解的播放方案。我在集成时还会额外做一步：用CoreWebView2Settings的AreDefaultScriptDialogsEnabled关掉页面上的 JS 弹窗，避免 H.265 播放器内部报错被拦截弹窗挡住。

还有一个隐藏坑：Edge 内核虽然支持 HEVC，但只有当显卡驱动正常、硬件解码器可用时才会开启硬解。你在开发机上测试没问题，交付到老显卡的工控机上就黑屏，需要先验证目标机器的 GPU 支持和驱动版本。所以，只要是播放视频类业务，我都会在需求阶段先确认“是否需要软解替代方案”，而不是看浏览器内核支持列表就拍板。

4.5 现象五：32 位/64 位混用导致内核组件“装不上”

程序跑起来直接报“已安装 32 位浏览器内核组件，覆盖安装暂不支持更改路径”，或类似提示。严格来说这是环境错误，不是代码错误，但非常常见。原因是你的应用是 32 位，但系统上安装了 64 位版本的 Fixed Version Runtime，或者反过来。

解决方式是明确 WebView2 发行渠道：Evergreen Runtime 是同时支持 32 位和 64 位进程的，不用担心；Fixed Version Runtime 则会区分位数。下载组件包时一定要选对架构，然后把你自己程序编译的主进程位数作为唯一标准。另外，如果你通过环境变量WEBVIEW2_BROWSER_EXECUTABLE_FOLDER指向一个固定目录，这个目录里的msedgewebview2.exe也必须和调用方位数一致，否则就会出现非常消耗耐心的启动失败。

我自己的项目，在初始化前会先调用GetAvailableCoreWebView2BrowserVersionString拿到当前可选浏览器版本，再和进程位数做一个断言，不匹配就直接抛错误检查，而不是等运行两三分钟才崩。这个习惯能帮你把绝大多数环境问题挡在门外。

5. 进阶能力：JS 注入、H.265 播放与离线部署的完整参数清单

5.1 AddScriptToExecuteOnDocumentCreated 注入脚本：时机、作用域与两个典型坑

除了消息通信，还有一种常用手段是注入 JavaScript。WebView2 提供两个注入入口：ExecuteScript在任意时刻向当前页面执行一段表达式；AddScriptToExecuteOnDocumentCreated则在每次文档创建时自动执行，常用于注入公共 API 或者覆盖全局函数。

m_webviewCore->AddScriptToExecuteOnDocumentCreated( L"window.__nativeBridge = { version: '1.0', platform: 'win32' };", Callback<ICoreWebView2AddScriptToExecuteOnDocumentCreatedCompletedHandler>( [](HRESULT error, PCWSTR id) -> HRESULT { // id 是注入脚本的标识，将来可用于 RemoveScript return S_OK; }).Get());

这里第一个坑是时机。AddScriptToExecuteOnDocumentCreated只在“之后创建的文档”上生效，已经加载完成的页面不会再次注入。所以你要先调用这个接口，再导航到业务页面；如果顺序反了，脚本只在第二次导航时才出现。第二个坑是作用域。注入的脚本运行在主世界，也就是页面脚本上下文；如果你使用ExecuteScript执行一个let变量，变量不会暴露到页面自身的window上，之后页面里后续代码读不到。要暴露全局对象，必须显式挂到window上，如上例所示。对，我踩过这个坑，当初以为注入后就全局可用了，结果页面里一直报未定义。

5.2 CoreWebView2Settings 三个高频开关：WebSecurity、状态栏与快捷键拦截

ICoreWebView2Settings接口控制运行时行为，最常调整的是下面三个开关：

CComPtr<ICoreWebView2Settings> spSettings; m_webviewCore->get_Settings(&spSettings); spSettings->put_AreDefaultScriptDialogsEnabled(FALSE); spSettings->put_IsStatusBarEnabled(FALSE); spSettings->put_AreBrowserAcceleratorKeysEnabled(FALSE);

这里我要特别说一句：IsWebSecurityEnabled默认是打开的，很多开发者在调试本地 HTML 时嫌同源策略碍事，直接关掉，然后忘了恢复。这个开关一旦关掉，网页里能访问任意端口、任意协议，黑客注入一段脚本就可能窃取本地文件数据。我一般只在带系统权限的本地工具类软件里关闭，并且只在线程池回调里设置，一旦页面加载完毕就恢复。如果你不希望浏览器状态栏出现在窗口右下角，那个角标是IsStatusBarEnabled控制的，设成 FALSE 即可。

5.3 离线部署 Fixed Version Runtime：目录结构、环境变量与注册表优先级

离线环境这里列一份标准做法。先把 Fixed Version Runtime 解压到C:\ProgramData\MyApp\WebView2\，目录里必须有msedgewebview2.exe和vcruntime140.dll等一套文件。然后有两种指定方式：环境变量和注册表。

推荐用环境变量，放在程序启动前设置，也可以直接在代码里在调用CreateCoreWebView2EnvironmentWithOptions前用SetEnvironmentVariable设置。实际取值优先级顺序是：代码里的browserExecutableFolder参数 > 环境变量WEBVIEW2_BROWSER_EXECUTABLE_FOLDER> 注册表。环境变量名如下：

WEBVIEW2_BROWSER_EXECUTABLE_FOLDER = C:\ProgramData\MyApp\WebView2 WEBVIEW2_USER_DATA_FOLDER = C:\ProgramData\MyApp\WebView2Data WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS = --disable-gpu --remote-debugging-port=9222

注册表方式是把上面这些键写在HKLM\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients对应的子键下，主要供无法改环境变量的托管环境使用。如果两种方式同时存在，环境变量优先于注册表，代码参数又优先于环境变量。我建议在交付说明里写清楚这个顺序，省的维护人员每次排查都搞不清到底是谁生效了。

还有一个点：Fixed Version Runtime 的目录不能有空格，路径里最好不要带中文，否则启动时可能出现奇怪的 Shell 路径拼接错误。这个我遇到过，当时把运行时放在D:\产品发布\浏览器内核\下，结果进程起不来，后来换了纯英文路径就好了。这种玄学问题排查最简单的方法就是路径全用 ASCII。

5.4 内存占用控制：MemoryUsageTargetLevel、用户数据目录与后台 Tab 回收

MFC 程序长期开着 WebView2，内存占用会慢慢涨，这是 Chromium 进程模型的常态。要压内存，主要手段有三个方面。

第一，设置MemoryUsageTargetLevel为LOW，让浏览器在后台自动回收内存。这个接口在某些历史版本里是实验性的，但在近一年版本里已经进入正式 API。设置方式是在环境创建时通过CoreWebView2EnvironmentOptions的put_MemoryUsageTargetLevel传入。低内存模式会降低后台页面性能，适合只在前台导航的场景。

第二，把userDataFolder控制在合理路径。这个目录会存放所有缓存、LocalStorage、IndexedDB，如果页面有大量写入操作，磁盘占用会增长到 GB 级别。一个常见的做法是退出时清掉 Cache 子目录，但保留 LocalStorage，因为有些登录状态需要保留。

第三，后台隐藏页面回收。多标签页场景下，把不可见标签对应的 WebView2 控制器put_IsVisible(FALSE)，并用ICoreWebView2Controller2::put_IsVisible控制渲染暂停。实际效果是，不可见的 WebView2 不会立刻释放内存，但会停止渲染合成，CPU 占用率显著下降。内存真正释放还是需要调用Close或者导航到about:blank。

6. 验证你就是真的在用 Edge 内核：一个最小检查脚本和一个排查习惯

验证 WebView2 是否真的用了 Edge 内核，最可靠的办法不是看着任务管理器里的msedgewebview2.exe，而是直接从页面里取 UA。我在集成完成后都会跑一段最小脚本：

m_webviewCore->ExecuteScript( L"JSON.stringify({ua: navigator.userAgent, platform: navigator.platform})", Callback<ICoreWebView2ExecuteScriptCompletedHandler>( [](HRESULT error, PCWSTR result) -> HRESULT { // result 是 JSON 字符串，包含 UA 和平台信息 // 浏览器里 UA 一般会包含 Edg/ 版本号 return S_OK; }).Get());

navigator.userAgent里如果包含Edg/，说明当前加载页面由 Chromium 内核渲染；如果还是MSIE或者Trident，说明你实际连到了老 IE 内核，初始化路径出了问题。除 UA 验证外，我还会检查 curl 一个本地调试端口来确认内核空闲进程是否正常，但这些都不如直接渲染一个display: grid页面来得直观。

我现在的习惯是每个新项目的需求阶段，就先确认目标机器的 WebView2 Runtime 版本和位数，把它写进交付部署文档的第一行。真正开始写代码前，先用官方示例跑通一遍环境，确认这个方案完整无缺，再去套到自己的 MFC 工程里。这样做的好处是，后续遇到的闪屏、布局、性能问题，你心里清楚是代码层的问题还是运行时的问题，不会把时间浪费在重复排查环境上。希望这份从选型到压坑的经验对正在考虑切换的你有点帮助。

本文还有配套的精品资源，点击获取