简介：面向需要在 VS2010、.NET Framework 4.0 环境中为 C# WinForm 应用嵌入浏览器内核的开发者，这份 CefSharp.Winform 49.0.1 示例代码提供了可参考的集成工程，适合想快速理解 Chromium 嵌入、控件初始化与页面交互的初、中级读者。压缩包共 319 个文件，约 189.28MB，包含 52 个 dll、174 个 pak 等 Chromium 运行依赖，以及 7 个 cs 源码、2 个 csproj、1 个 sln、若干 xml、config、nupkg 与 pdb 文件，便于对照工程结构、编译产物和依赖还原线索。已有 3432 人学习下载。读者可查看主窗体加载 ChromiumWebBrowser、Cef.Initialize 配置、页面加载状态监听、ExecuteScriptAsync 执行 JavaScript 及退出时 Cef.Shutdown 等关键代码，也能参考禁用 GPU、设置缓存路径等自定义项，并借助完整解决方案快速复现内置浏览器，为请求拦截、脚本注入等扩展开发打底。

1. 老 WinForm 里塞一个现代浏览器：CefSharp 在 .NET 4.0 上的最后一块拼图

手上有一套跑了七八年的 WinForm 桌面程序，目标框架写死在 .NET 4.0，开发机还装着 VS2010，最近要加一个内嵌网页的场景——登录页、报表看板、第三方页面回跳。系统自带的 WebBrowser 控件走的是 IE 内核，遇到 CSS3 的 flex 布局和 ES6 的箭头函数直接瘫掉，页面花得没法看。搜「C# WinForm CefSharp 示例」能找到一堆教程，绝大多数都默认你用的是 .NET 4.5.2 以上，直接照抄必翻车。这份示例代码针对的就是这段版本夹缝：用 CefSharp.WinForms 在 VS2010 + .NET 4.0 下把 Chromium 内核嵌进窗体，能编译、能跑、能双向通信。适合手里有存量老项目、短期内又没法升级框架的从业者。

2. 版本选型：把 CefSharp 锁在 49 分支的三个理由

2.1 .NET 4.0 的天花板究竟在哪

很多人第一反应是「装个最新版不就行了」，于是打开 NuGet 搜 CefSharp.WinForms，装完编译就报一串红。问题不在代码，在版本。CefSharp 从 51 分支开始把最低框架要求提到了 .NET 4.5.2，而 49.x 是最后一条完整支持 .NET 4.0 的线。这不是「建议」，是硬约束：51 之后的 lib 目录里只有 net45 及以上的目标程序集，VS2010 的 .NET 4.0 项目根本解析不到。

同样被排除的还有几个常见替代方案。WebView2 需要在目标机器上装 Evergreen Runtime，而且对操作系统版本有要求，老旧的 Win7 生产线机器上大概率装不上；CEF 官方的 C# 绑定早就停止维护，文档散落在各处；至于直接用 libcef.dll 做 P/Invoke，光是初始化回调的头文件映射就够折腾一周。所以在「不改框架版本」这个前提下，CefSharp 49.x 基本是唯一解。

这里有个容易混淆的点：49.x 自己也有多个小版本，49.0.1 是这条线上打包最完整、被引用最多的一个。它的 CefSharp.Common 包同时提供 net40 和 net45 两个目标，装的时候 NuGet 会自动按项目的目标框架挑，选错了就是编译期报「找不到类型或命名空间名 ChromiumWebBrowser」。

还有一条经常被忽略：CefSharp 的托管层是 C++/CLI 混合程序集，依赖 VC++ 2013 的 x86 或 x64 运行库。目标机器上如果没装过，启动时会直接抛DllNotFoundException，报的却是 libcef.dll 找不到，很容易误判成文件没拷全。我一般在部署包里顺手带上vcredist_x86.exe，安装脚本里静默跑一遍，比事后远程排查省事得多。

2.2 VS2010 里装 CefSharp 的两种姿势

VS2010 能用的 NuGet 扩展版本很老，最后一条支持它的线停在 2.8.x 附近，对 v3 的包源支持有限，搜索时经常卡住或者返回空结果。所以实际落地有两条路。

第一条是走 NuGet，但先把包源切到 v2 地址，然后直接用命令行装，绕开 IDE 图形界面的兼容问题。仓库根目录下要有.nuget文件夹或者直接用全局的 nuget.exe。

# 在解决方案根目录执行，nuget.exe 放在 PATH 里或者写全路径 nuget install CefSharp.Common -Version 49.0.1 -OutputDirectory packages -Source https://www.nuget.org/api/v2 nuget install CefSharp.WinForms -Version 49.0.1 -OutputDirectory packages -Source https://www.nuget.org/api/v2

两条命令的-Version必须完全一致，-OutputDirectory指向解决方案同级的 packages 目录，这样packages.config里的相对路径才认得出来。装完不会自动改项目文件，得在 VS2010 里手动「添加引用」，从packages\CefSharp.Common.49.0.1\lib\net40和packages\CefSharp.WinForms.49.0.1\lib\net40两个目录挑 dll。

第二条路是手工解包。把 nupkg 当 zip 改后缀解开，把lib\net40下的三个托管 dll 和build目录下的原生文件按结构摆到项目里，引用直接指向本地路径。这条路的好处是不依赖任何 NuGet 客户端，坏处是升级和回滚全靠手工记账。我一般只在前一种方式彻底走不通时才用它，比如客户的内网机器完全断网。

无论走哪条路，都得在项目根目录补一个packages.config，把它纳入源码管理，否则换台机器重新拉代码，引用的路径全会变成红色。

<?xml version="1.0" encoding="utf-8"?> <packages> <!-- targetFramework 必须写 net40，写成 net45 会导致引用解析到错误的 lib 目录 --> <package id="CefSharp.Common" version="49.0.1" targetFramework="net40" /> <package id="CefSharp.WinForms" version="49.0.1" targetFramework="net40" /> </packages>

targetFramework这个属性看着不起眼，但它决定了还原时去哪个子目录找 dll。手写过一次 net45，编译能过，运行时却报类型加载失败，查了半天才发现引用的根本不是同一个程序集。

2.3 输出目录该长什么样

CefSharp 最容易出问题的地方不在代码，在文件摆放。托管 dll 在输出根目录，原生文件在x86\或x64\子目录里，少一个就白屏。下面这张表是我每次新建项目后逐项核对的清单，对着bin\Debug一条条看，比看异常堆栈快。

locales目录里不需要全部语言包，保留en-US.pak和zh-CN.pak两个就够，能把部署体积压下来十几兆。但这两个一旦删掉，CEF 会回退到内置的英文资源，界面上会出现中英文混排，用户第一眼就觉得这软件没做完。

还有一点：libcef.dll的位数必须和项目的平台目标一致。x86 的进程加载 x64 的 libcef，BadImageFormatException会在初始化阶段就抛出来；反过来一样。这也是为什么后面要强调平台目标不能留 AnyCPU。

3. 最小可运行示例：从空项目到跑起一个浏览器

3.1 项目属性里三处必改

新建 WinForm 项目后先别急着写代码，有三处不改，后面全是坑。

第一处是目标框架。VS2010 新建项目默认给的往往是.NET Framework 4 Client Profile，这是个精简子集，不包含 CefSharp 依赖的部分程序集。在「项目属性 → 应用程序 → 目标框架」里改成完整的.NET Framework 4，改完 VS 会重载项目。

第二处是平台目标。在「项目属性 → 生成 → 目标平台」里，把AnyCPU改成x86或者x64，跟你要部署的 libcef 位数对齐。AnyCPU 在 64 位系统上会以 64 位进程启动，而如果你的x86\libcef.dll是 32 位的，加载必然失败。这条在 64 位开发机上尤其隐蔽，因为开发机往往两套运行库都装了，本机能跑，换台机器就崩。

第三处是 App.config。CefSharp.Core 是混合模式程序集，.NET 4.0 默认的运行时激活策略会拒绝加载它，需要在配置里显式放行。

<?xml version="1.0" encoding="utf-8"?> <configuration> <startup useLegacyV2RuntimeActivationPolicy="true"> <!-- sku 必须和项目实际目标框架一致，写错会导致配置节被忽略 --> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" /> </startup> <runtime> <!-- 工作站 GC 在频繁创建销毁浏览器实例时更容易出现长暂停 --> <gcServer enabled="true" /> </runtime> </configuration>

useLegacyV2RuntimeActivationPolicy="true"是这个场景下最关键的一行，作用是让 CLR 用旧版的程序集绑定策略去加载混合模式程序集。少了它，程序会在Cef.Initialize那一行抛FileLoadException，提示「混合模式程序集是针对 v2.0.50727 版运行时生成的」，而项目明明是 .NET 4.0，这个提示会把人带偏。

gcServer那行属于可选项。如果你的应用会同时开多个浏览器实例，打开服务端 GC 能明显减少卡顿；只是单窗口展示网页的话，关掉也没影响。

3.2 初始化顺序与 CefSettings 参数

CefSharp 的初始化有个硬约束：整个进程生命周期内只能调一次Cef.Initialize，而且必须在任何浏览器实例创建之前。把这段代码放进Program.Main是最稳妥的做法，放窗体构造函数里迟早会踩到「第二次打开窗口就崩」。

using System; using System.IO; using System.Windows.Forms; using CefSharp; namespace CefWinformDemo { static class Program { [STAThread] static void Main() { var settings = new CefSettings { // 界面语言，影响内置错误页和右键菜单 Locale = "zh-CN", // 日志级别调到 Warning，Info 级别会写出几十兆的日志文件 LogSeverity = LogSeverity.Warning, LogFile = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "cef.log"), // 缓存目录别放在程序目录下，Program Files 没有写权限 CachePath = Path.Combine( Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), "CefWinformDemo", "cache"), // 有些服务端会校验 UA，这里给个能识别的标识 UserAgent = "CefWinformDemo/1.0 (Windows NT 6.1)" }; // 老机器没有独显，强制软件渲染，避免整片白屏 settings.CefCommandLineArgs["disable-gpu"] = "1"; settings.CefCommandLineArgs["disable-gpu-compositing"] = "1"; // 关掉内置 PDF 预览，交给系统默认程序打开 settings.CefCommandLineArgs["disable-pdf-extension"] = "1"; // performDependencyCheck=true 会在启动时校验原生 dll 的位数和完整性， // 缺文件直接抛异常，比运行到一半白屏好排查十倍 Cef.Initialize(settings, performDependencyCheck: true, browserProcessHandler: null); Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new MainForm()); // 必须在所有窗体关闭之后调用，顺序反了会卡死在这里 Cef.Shutdown(); } } }

几个参数值得单独拿出来说。CachePath指向LocalAppData而不是程序目录，是因为很多部署场景把程序装在Program Files下，普通用户对那个目录没有写权限，CEF 尝试建缓存目录失败后不会报错，只是默默退化成无缓存模式，表现是每次启动都要重新加载资源。performDependencyCheck在发布版里可以关掉省几十毫秒启动时间，但开发阶段一定打开，它能在第一现场把「文件没拷全」和「位数不匹配」这两类问题挡下来。

CefCommandLineArgs是个键值字典，往里面塞的就是 Chromium 的命令行开关。disable-gpu这条在虚拟机和远程桌面环境下几乎必加，否则会看到一片纯白，控制台里刷GPU process isn't usable之类的日志。代价是页面滚动会稍微不那么跟手，但至少能看见东西。

3.3 控件挂载与首屏加载

窗体这一层的代码不多，但事件挂载的顺序会影响首次导航能不能拿到回调。

using System; using System.Collections.Generic; using System.IO; using System.Windows.Forms; using CefSharp; using CefSharp.WinForms; namespace CefWinformDemo { public partial class MainForm : Form { private ChromiumWebBrowser _browser; public MainForm() { InitializeComponent(); Text = "CefSharp on .NET 4.0"; Width = 1200; Height = 800; _browser = new ChromiumWebBrowser("about:blank") { Dock = DockStyle.Fill }; // 事件必须在 Load 之前挂，否则首次导航的状态变化收不到 _browser.LoadingStateChanged += OnLoadingStateChanged; _browser.FrameLoadEnd += OnFrameLoadEnd; _browser.ConsoleMessage += OnConsoleMessage; Controls.Add(_browser); var localPage = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "web", "index.html"); _browser.Load(localPage); } private void OnLoadingStateChanged(object sender, LoadingStateChangedEventArgs e) { // IsLoading 会来回翻转，只在主框架上做 UI 联动 if (!e.Browser.IsLoading) { BeginInvoke(new Action(() => Text = "加载完成")); } } private void OnFrameLoadEnd(object sender, FrameLoadEndEventArgs e) { // 子 iframe 也会触发，不做这层判断会重复注入脚本 if (!e.Frame.IsMain) return; e.Frame.ExecuteScriptAsync( "document.title = 'CefSharp Demo - ' + location.pathname;"); } private void OnConsoleMessage(object sender, ConsoleMessageEventArgs e) { // 前端的 console.log 会走到这里，排查白屏时非常有用 System.Diagnostics.Debug.WriteLine("[JS] " + e.Message); } protected override void OnFormClosing(FormClosingEventArgs e) { // 先释放浏览器再关窗体，反过来容易出现跨线程访问已释放对象 if (_browser != null) { _browser.Dispose(); _browser = null; } base.OnFormClosing(e); } } }

ConsoleMessage这个事件值得单独提一句。前端页面白屏、脚本报错，在 WinForm 里是看不到 F12 的，把console.log和console.error接到这个事件上输出到调试窗口，等于给自己装了个黑匣子。我在排查「页面在浏览器里正常、嵌进客户端就报错」这类问题时，第一件事就是挂这个事件。

FrameLoadEnd里的IsMain判断也不能省。一个带 iframe 的页面会触发多次FrameLoadEnd，不判断就会在子框架里重复执行注入脚本，轻则重复弹窗，重则死循环。

页面文件放在输出目录下的web\index.html，内容先写个最小的，验证链路通不通：

<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title>Demo</title> </head> <body> <h1 id="title">等待注入</h1> <button onclick="alert('clicked')">点我</button> </body> </html>

跑起来如果能看到标题被改成带路径的字符串，说明渲染、脚本注入、事件回调三条链路都通了。这一步过了，后面加功能才有意义。

4. 双向通信：C# 调 JS 与 JS 回调 C# 的完整链路

4.1 C# 调 JS：两个方法的返回值差异

CefSharp 提供了两个执行脚本的入口，名字很像，语义完全不同，混用会让返回值解析出错。

ExecuteScriptAsync只负责执行，返回的是脚本最后一句表达式值的 JSON 序列化字符串。注意是字符串，拿到"12"时还得再反序列化一次才是数字。EvaluateScriptAsync会尝试把结果转成 .NET 对象，返回一个JavascriptResponse结构，带Success、Result、Message三个属性，更适合需要判断执行成功与否的场景。

private async void btnRunJs_Click(object sender, EventArgs e) { // 场景一：只关心副作用，不需要返回值 await _browser.GetMainFrame().ExecuteScriptAsync( "document.body.style.backgroundColor = '#f5f5f5';"); // 场景二：要拿一个简单值。返回的是 JSON 文本，数字会带引号 string rawCount = await _browser.GetMainFrame() .ExecuteScriptAsync("document.querySelectorAll('a').length;"); // rawCount 形如 "12"，用 Convert 或反序列化转成 int int linkCount = Convert.ToInt32(rawCount); // 场景三：要拿结构化结果，用 EvaluateScriptAsync JavascriptResponse resp = await _browser.EvaluateScriptAsync( "({ title: document.title, url: location.href, height: document.body.scrollHeight })"); if (resp.Success && resp.Result is IDictionary<string, object> dict) { string title = dict["title"].ToString(); string url = dict["url"].ToString(); // 对象里的数值是 long 或 double，直接强转 int 会抛 InvalidCastException long height = Convert.ToInt64(dict["height"]); MessageBox.Show(string.Format("{0}\r\n{1}\r\n高度 {2}", title, url, height)); } else { // Message 里是具体的 JS 异常信息，比一句"执行失败"有用得多 MessageBox.Show("脚本执行失败: " + resp.Message); } }

这里有个反复踩的细节：EvaluateScriptAsync返回的字典里，整型数字是long而不是int。直接写(int)dict["height"]会在运行时抛InvalidCastException，编译期完全看不出来。我现在的习惯是只要从 JS 拿数字，一律走Convert.ToInt64或Convert.ToDouble，不多想。

还有一个前置条件：GetMainFrame()在页面还没开始加载时返回的IFrame上执行脚本，可能什么都不发生。稳妥的做法是把调用挂在LoadingStateChanged里IsLoading == false之后，或者干脆等到FrameLoadEnd。

4.2 JS 调 C#：RegisterJsObject 的同步语义

反向通信靠绑定。CefSharp 49 里有两套 API，RegisterJsObject走的是老式同步绑定，JS 端调用后直接拿到返回值，不用写.then()；RegisterAsyncJsObject返回 Promise，前端得改成异步写法。老项目里前端代码往往是现成的，我一般优先选前者，改动最小。

绑定对象得是一个 public 类，暴露的方法也得是 public，参数和返回值都要求能被序列化。

using System; using System.Windows.Forms; namespace CefWinformDemo { public class JsBridge { // 无参有返回值，JS 端同步拿到字符串 public string GetVersion() { return "1.0.0"; } public string GetMachineName() { return Environment.MachineName; } // 返回匿名对象，CefSharp 会序列化成 JSON 交给 JS public object QueryOrder(string orderId) { if (string.IsNullOrEmpty(orderId)) { return new { code = 400, message = "orderId 不能为空" }; } return new { code = 0, data = new { orderId = orderId, amount = 199.00m, state = "PAID", createdAt = DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss") } }; } // 无返回值，用来给 C# 侧发通知 public void Notify(string level, string message) { // JS 调用进来时不在 UI 线程，直接弹窗会抛跨线程异常 var form = Application.OpenForms["MainForm"]; if (form == null) return; form.BeginInvoke(new Action(() => { MessageBox.Show(form, message, level); })); } } }

注册的时机很关键，必须在浏览器控件创建之后、页面开始加载之前。

// 放在 MainForm 构造函数里，_browser 创建之后、Load 之前 var bridge = new JsBridge(); _browser.RegisterJsObject("bridge", bridge, new BindingOptions { // 默认就是 true，C# 的 GetVersion 在 JS 里变成 getVersion // 显式写出来是为了避免以后换版本默认值变了 CamelCaseJavascriptNames = true });

CamelCaseJavascriptNames这个开关是个高频翻车点。打开时 C# 的GetVersion在 JS 里叫getVersion，首字母小写；关掉时保持原样。前端同学按文档写了bridge.GetVersion()结果报 undefined，八成就是这里对不上。我现在的做法是统一打开，然后在页面里加一段自检，启动时打印一遍可用方法名。

页面侧的调用：

<script> // 同步绑定，直接拿返回值 var ver = bridge.getVersion(); document.getElementById('title').innerText = '版本 ' + ver; // 传参 + 拿对象 var result = bridge.queryOrder('A1001'); if (result.code === 0) { console.log('金额 ' + result.data.amount); } else { console.error(result.message); } // 回调 C# 弹窗 bridge.notify('提示', '页面加载完毕'); </script>

result拿到的就是反序列化后的 JS 对象，result.data.amount能直接点出来。如果返回 null 或者 undefined，先查两个地方：绑定是否在页面加载前完成，以及方法名大小写。

4.3 传对象、传数组与异常回传

参数序列化这块有几个边界值得记下来。

传数组时，C# 侧声明成object[]或者具体类型的数组都行，但数组里的元素类型要保持一致，混着放字符串和数字会导致部分元素变成 null。我一般让前端把复杂结构先JSON.stringify成字符串再传，C# 侧用Newtonsoft.Json反序列化，虽然多一步，但可控性高得多，出问题也容易定位。

传日期是个典型陷阱。C# 的DateTime序列化后是 ISO 8601 格式的字符串，前端拿到手不能直接当 Date 用，得先new Date(str)转一道。反过来，前端传时间戳进来，C# 侧收到的是long或者double，得自己判断是秒还是毫秒。

异常回传更需要注意。绑定方法里抛出的异常不会让 JS 端崩溃，而是被 CefSharp 吞掉，JS 侧拿到的是 undefined，控制台里什么都没有。这属于典型的黑匣子场景：前端说「调了没反应」，后端说「我没收到请求」。我的处理方式是在桥接层包一层 try-catch，把异常信息序列化后返回给 JS，让前端至少能打出来。

public object SafeCall(string action, string payload) { try { // 实际业务分发逻辑放在这里 return new { code = 0, data = payload }; } catch (Exception ex) { // 必须自己兜住，否则 JS 侧只会看到 undefined return new { code = 500, message = ex.GetType().Name + ": " + ex.Message }; } }

返回值统一成{ code, message, data }三段式，前端判断code就能区分成功和失败，比靠 undefined 猜要靠谱。这套约定看着笨，但在没有调试器的嵌入环境里，它是唯一能让前端自己定位问题的办法。

5. 避坑排查：五条让我重装过系统的血泪记录

5.1 启动与加载类问题

现象一：编译通过，运行时白屏，什么异常都没有。

原因通常是x86\libcef.dll没被拷到输出目录，或者平台目标留在了 AnyCPU，导致 64 位进程去加载 32 位的原生库。CEF 在这种情况下不一定抛异常，有时就那么静静地白着。解决办法是把Cef.Initialize的performDependencyCheck参数设成true，让它在启动阶段就检查文件完整性并抛出明确异常；同时检查「项目属性 → 生成 → 目标平台」是否已经固定成 x86。改完记得清理一次bin和obj，VS2010 的增量编译在这块偶尔会留下旧文件。

现象二：程序一闪就退，事件查看器里能看到FileLoadException，提示混合模式程序集是针对 v2.0.50727 生成的。

这是App.config里缺了useLegacyV2RuntimeActivationPolicy="true"。CefSharp.Core 是 C++/CLI 编译出来的混合程序集，.NET 4.0 默认的绑定策略会拒绝加载它。补上那一行配置即可，注意supportedRuntime的sku要和项目实际框架版本对上，写成v4.5会导致整个配置节被忽略，症状照旧。

5.2 通信与脚本类问题

现象三：JS 里调bridge.getVersion()报bridge is not defined。

三个常见原因，按概率排序：一是RegisterJsObject调用时机晚于页面加载，页面里的脚本已经在执行了，绑定还没挂上；二是脚本跑在 iframe 里，而绑定只注册在主框架，子框架访问不到；三是前端写成了bridge.GetVersion()，而CamelCaseJavascriptNames是打开的，实际方法名首字母小写。解决方式分别是把注册挪到构造函数里、在子框架内用window.parent.bridge访问、统一命名规范并在页面启动时打印一遍方法名做自检。

现象四：JS 调 C# 方法，前端拿到 undefined，C# 侧断点也没进。

大概率是绑定方法内部抛了异常被吞掉了。CefSharp 的绑定调用默认不会把异常传回 JS，只是返回 undefined。排查手段是在方法体第一行加日志，确认有没有进去；进去之后再逐段注释定位。长期方案是像上一节说的那样，所有暴露给 JS 的方法都包一层 try-catch，把异常转成结构化返回值。

5.3 退出与资源释放类问题

现象五：窗体关了进程还在，任务管理器里能看到残留的CefSharp.BrowserSubprocess.exe。

这是释放顺序错了。正确顺序是先_browser.Dispose()，等所有窗体关闭、Application.Run返回之后再调Cef.Shutdown()。如果反过来，Shutdown时子进程还在跑，主进程会卡在等待上，表现出来就是窗口没了但进程不退。还有一种情况是把Cef.Initialize写在了窗体构造函数里，用户开第二个窗口时重复初始化，抛出的异常被 WinForm 的全局异常处理吃掉，进程就挂在那了。初始化只做一次，放在Program.Main，这条没有例外。

6. 进阶收尾：多实例缓存隔离与生命周期管理

单窗口场景跑通之后，接下来多半会遇到「同一个客户端里开多个页面」的需求。最直接的做法是new多个ChromiumWebBrowser塞进TabControl，但这么干会共享同一个默认RequestContext，Cookie 和缓存全混在一起，A 标签页登录了，B 标签页自动带上身份，做多账号场景时完全没法用。

正确姿势是给每个需要隔离的实例单独建RequestContext：

private ChromiumWebBrowser CreateIsolatedBrowser(string url, string profileName) { var ctxSettings = new RequestContextSettings { // 每个 profile 一个缓存目录，互不干扰 CachePath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "profiles", profileName, "cache"), // 会话 Cookie 落盘，重启后还能保持登录态 PersistSessionCookies = true, AcceptLanguageList = "zh-CN,zh;q=0.9" }; var context = new RequestContext(ctxSettings); var browser = new ChromiumWebBrowser(url, context) { Dock = DockStyle.Fill }; // 浏览器销毁时同步释放上下文，否则缓存目录句柄一直被占着 browser.Disposed += (s, e) => { try { context.Dispose(); } catch { } }; return browser; }

CachePath里带上 profile 名，等于给每个实例划了一块独立的地盘。这里有个我踩过的坑：目录名不能用中文和空格，CEF 内部对路径的处理在某些代码页下会出问题，表现是缓存写不进去但也不报错。还有RequestContext的数量不要太多，每个上下文背后是一套独立的缓存和网络栈，开十几个会让内存曲线很难看，实际用三到五个够覆盖绝大多数场景。

生命周期上还有两个收尾动作值得写进基类。一是监听IsBrowserInitializedChanged，在这个事件里再去做Load和脚本注入，比在构造函数里直接调更稳；二是在Disposed里解绑所有事件，FrameLoadEnd、LoadingStateChanged、ConsoleMessage这几个如果挂着匿名委托，很容易在窗口关闭后还持有着窗体引用，造成内存泄漏。

验证释放是否干净有个笨办法但很好用：反复打开关闭同一个窗口二十次，看任务管理器里进程的私有工作集是否稳定在某个值附近。如果每次关闭后内存都在涨，基本就是事件没解绑或者Disposed里漏了context.Dispose()。我现在的习惯是每加一个浏览器实例，就在关闭流程里断点走一遍，确认Dispose被调到、进程数回落到基线，再往下写业务。这套动作花不了两分钟，但能省掉后面几天的内存排查。希望帮到你。

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