简介：这是一份面向C# WinForm开发者的CefSharp.Winform集成示例包，重点解决在VS2010与.NET Framework 4.0环境下为桌面程序嵌入Chromium浏览器内核的问题，适合需要实现内置网页浏览、页面事件监听与JavaScript交互的开发者参考。压缩包为rar格式，共319个文件，约189.28MB，包含cs源码、csproj项目与sln解决方案，以及dll依赖库、pak浏览器资源、xml配置说明和pdb、bin、exe、nupkg等运行文件，覆盖示例项目从源码到依赖运行的完整结构。已有3440人学习下载。示例围绕Cef初始化、ChromiumWebBrowser控件加载、加载状态与导航事件处理、脚本执行及CefSettings自定义展开，并涉及退出时的资源释放，便于读者对照搭建可运行的WinForm浏览器原型，并在此基础上扩展请求拦截、脚本注入等需求。对于仍在使用旧版开发环境的维护项目，可减少从零配置依赖与资源目录的摸索成本；也可作为窗体项目与配置项衔接关系的对照材料。

1. VS2010 + .NET 4.0 里换掉 IE 内核：CefSharp.WinForms 这套示例代码到底还能不能用

接手一个老 WinForm 桌面端，客户机器锁死在 .NET 4.0，开发机还停在 VS2010，产品却要求把内置的 WebBrowser 控件换成 Chromium——这类需求落到最后，绕不开 CefSharp.WinForms 的一套示例代码。我在这种组合上折腾过几轮，最深的体会是：能不能跑起来，跟代码写得漂不漂亮关系不大，跟版本卡得准不准关系极大。新分支早就把 .NET 4.0 抛在身后，老 NuGet 客户端也不认现在的包结构。真正要解决的就三件事：挑一个还吃 .NET 4.0 的分支、绕过装包环节、把 AnyCPU 改成明确的 x86 或 x64。下面按我落地的顺序，把最小示例、C# 与页面互操作、以及部署时几处翻车点讲清楚。

2. 版本卡位与工程骨架：先把 .NET 4.0 能吃的那个分支钉死

动手之前先接受一个事实：CefSharp.WinForms 不是一个独立的东西，它是「托管封装层 + Chromium 原生二进制 + 若干资源文件」三件套。托管层用 C# 写，负责把 Chromium 的多进程模型包成 .NET 控件；原生层是几个几十兆的 DLL 和数据文件，跑在渲染子进程里。两边的版本必须严格配对，混一个版本就是 BadImageFormatException 或者启动即崩。所以第一步不是写代码，是把版本和工程骨架定下来。

2.1 CefSharp 版本与 .NET 4.0 的边界画在哪

CefSharp 的版本号跟 Chromium 主版本号是绑定的，49.x 对应 Chromium 49，51.x 对应 Chromium 51，往上一直这么排。托管程序集的目标框架随版本推进，从 51 那一批开始就把最低框架要求抬到了 .NET 4.5.2，后面的分支再没回过头。也就是说，想留在 .NET 4.0，能选的就只有 49.x 及其之前的分支。这个边界非常硬，没有配置文件能绕过去。

我在选型时一般按这张表权衡：

选 49.x 意味着放弃一部分现代前端能力。flex 布局、CSS 变量基本能用，但一些新语法、新的 Web API 就别指望了。如果页面是自己团队维护的，用构建工具把语法降级到 ES5、把新特性做 polyfill，问题不大；如果不巧要嵌第三方站点，那就要提前验证，别等上线才发现某个页面控件错位。

确定分支后，还要确认一件事：这个分支的托管程序集是不是真的面向 net40。最简单的验证方式是打开 nupkg 里的 lib 目录，看子目录名是不是 net40。如果是 net45，那你装上去之后项目引用会带黄色感叹号，编译报找不到类型。

2.2 VS2010 的 NuGet 太老，用 nuget.exe 命令行绕过去

VS2010 时代配套的 NuGet 扩展版本很低，包源格式和现在的主流源有代差，图形界面里搜包、装包经常直接报错退出。我试过换源、清缓存、重装扩展，成功率不稳定。后来干脆放弃图形界面，直接走命令行，一次装完。

从包管理命令行工具所在目录执行：

:: 先确认 nuget.exe 本身的版本够新，老版本同样解析不了现代包源 nuget help :: 把托管包和它依赖的原生包一次性拉到本地 packages 目录 :: -Version 填你在 2.1 里确认过的、面向 net40 的那个版本 nuget install CefSharp.WinForms -Version 49.0.1 -OutputDirectory ..\packages -NonInteractive :: 装完检查目录，应该能看到三个并列的文件夹 dir ..\packages /b

-OutputDirectory指定落盘位置，习惯放在解决方案同级的 packages 目录，跟 VS 默认行为一致。-NonInteractive让它在遇到确认提示时直接走默认选项，避免卡在交互上。命令跑完，..\packages下应该出现CefSharp.WinForms.x、CefSharp.Common.x、cef.redist.x86（或 x64）这几个目录，缺哪个就说明依赖没解析全，通常是源里没有对应的原生包版本。

如果连命令行都拉不下来，还有第二种绕法：手动把 nupkg 文件下下来，改后缀为 zip 解压，把 lib\net40 下的托管 DLL 和 build 目录下的 targets 文件拷到工程里，然后手工加引用。这种方式最脏，但最不依赖环境，我在完全离线的客户内网里用过几次。

装好之后还有一步容易漏：老版本 NuGet 有时不会把包里的 targets 文件自动注入 csproj。打开项目文件看一眼，如果没有下面这段，手工补上，否则原生 DLL 不会被复制到输出目录：

<!-- 放在 </Project> 之前，路径按实际解压位置调整 --> <Import Project="..\packages\CefSharp.Common.49.0.1\build\CefSharp.Common.targets" Condition="Exists('..\packages\CefSharp.Common.49.0.1\build\CefSharp.Common.targets')" />

Condition里的Exists判断不是可有可无的装饰。多人协作时 packages 目录一般不进版本库，条件不成立就跳过导入，项目还能正常打开，不至于因为一个缺失文件导致整个解决方案加载失败。

2.3 三处 csproj 改动：把 AnyCPU 拆成明确的 x86 与 x64

这是最容易翻车的地方。CefSharp 带原生 DLL，进程位数必须跟原生 DLL 位数对上。而 VS2010 的默认平台是 AnyCPU，在 64 位系统上会以 64 位进程运行，加载 32 位的 libcef.dll 就直接抛 BadImageFormatException，报错信息还很不友好，新手经常误以为是缺文件。

解决办法是在项目属性里把平台目标改成 x86 或 x64，并且给每个平台配独立的输出目录。手工改 csproj 比在图形界面点更可控，我一般直接编辑 XML：

<!-- 1) 声明两个平台，VS 的配置下拉里才会出现 x86 选项 --> <PropertyGroup> <Platforms>AnyCPU;x86;x64</Platforms> </PropertyGroup> <!-- 2) 每个平台独立输出目录，避免两套原生 DLL 互相覆盖 --> <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' "> <DebugSymbols>true</DebugSymbols> <OutputPath>bin\x86\Debug\</OutputPath> <DefineConstants>DEBUG;TRACE</DefineConstants> <!-- 3) 关键：锁死进程位数 --> <PlatformTarget>x86</PlatformTarget> <ErrorReport>prompt</ErrorReport> <WarningLevel>4</WarningLevel> </PropertyGroup> <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' "> <OutputPath>bin\x86\Release\</OutputPath> <DefineConstants>TRACE</DefineConstants> <PlatformTarget>x86</PlatformTarget> <Optimize>true</Optimize> <WarningLevel>4</WarningLevel> </PropertyGroup>

第一处<Platforms>决定解决方案配置管理器里能不能选出 x86；第二处<OutputPath>分开目录，是因为 x86 和 x64 的解压目录里放的是同名但不同位数的 libcef.dll，共用输出目录时后一次生成会覆盖前一次，表现就是「昨天还好好的，今天换了个配置就崩」；第三处<PlatformTarget>才是真正生效的那个开关，只改平台名不改它，进程位数还是按 AnyCPU 走。

如果客户环境不确定是 32 位还是 64 位系统，统一出 x86 版本最省心，32 位进程在 64 位系统上能正常跑。代价是 x86 进程有 2GB 虚拟地址空间上限，长时间开着复杂页面容易内存吃紧，这一点在第 6 章还会提。

3. 最小可运行示例：一个窗体、一个浏览器控件、一份初始化配置

骨架搭好之后，代码本身其实很短。CefSharp 的用法可以浓缩成三句话：进程启动时初始化一次，窗体里挂一个 ChromiumWebBrowser 控件，进程退出前关一次。真正需要斟酌的是初始化放在哪、参数怎么给、关闭顺序怎么排。

3.1 Program.cs：Cef.Initialize 的位置和顺序

初始化必须早于任何 ChromiumWebBrowser 实例的创建，而且全局只能调一次。我习惯放在 Main 里，Application.Run 之前：

using System; using System.IO; using System.Windows.Forms; using CefSharp; namespace CefDemo { static class Program { [STAThread] static void Main() { var baseDir = AppDomain.CurrentDomain.BaseDirectory; var settings = new CefSettings(); // 缓存与日志都落到程序目录下，别用默认的用户目录， // 老机器上经常因为权限问题写不进去，表现为白屏且无任何报错 settings.CachePath = Path.Combine(baseDir, "cef_cache"); settings.LogFile = Path.Combine(baseDir, "cef.log"); settings.LogSeverity = LogSeverity.Info; // 语言与 Accept-Language，很多站点靠这个决定返回中文还是英文 settings.Locale = "zh-CN"; settings.AcceptLanguageList = "zh-CN,zh;q=0.9,en;q=0.8"; // 虚拟机和远程桌面下 GPU 合成经常失败，直接关掉最稳 settings.CefCommandLineArgs.Add("disable-gpu", "1"); settings.CefCommandLineArgs.Add("disable-gpu-compositing", "1"); // 本地 HTML 想读同目录文件时加这条，否则会被同源策略挡住 settings.CefCommandLineArgs.Add("allow-file-access-from-files", "1"); // 子进程可执行文件必须能被找到，找不到时渲染和 JS 绑定会静默失效 var subProcess = Path.Combine(baseDir, "CefSharp.BrowserSubprocess.exe"); if (File.Exists(subProcess)) { settings.BrowserSubprocessPath = subProcess; } // 全局只允许调用一次，重复调用会抛异常 Cef.Initialize(settings); Application.Run(new MainForm()); // 必须在消息循环结束之后、进程退出之前调用 Cef.Shutdown(); } } }

CachePath和LogFile指向BaseDirectory而不是默认位置，是因为不少企业机器的用户目录有重定向或者写权限限制，缓存写不进去时 Chromium 不会弹错误，只是页面渲染异常，排查起来非常痛苦。日志级别给 Info 就够，Trace 会写出巨量内容，磁盘很快就满。

BrowserSubprocessPath这段加了File.Exists判断，是因为不同小版本里这个文件的名字和位置有差异，硬编码路径一旦对不上，程序不报错但 JS 绑定和部分渲染能力直接失效，属于典型的黑匣子问题。先判断再加，至少不会因为路径写错把整个初始化搞崩。

disable-gpu这两条是血泪经验。开发机上有独立显卡时一切正常，一放到虚拟桌面或者远程会话里就白屏，日志里只有一行 GPU 进程启动失败的警告。加上之后走软件渲染，帧率低一点但至少能看见东西。

3.2 MainForm.cs：ChromiumWebBrowser 的挂载与事件

窗体这一层就是把控件铺满、注册桥接对象、接几个关键事件：

using System; using System.Windows.Forms; using CefSharp; using CefSharp.WinForms; namespace CefDemo { public partial class MainForm : Form { private ChromiumWebBrowser _browser; public MainForm() { InitializeComponent(); Text = "内嵌浏览器"; Width = 1280; Height = 800; StartPosition = FormStartPosition.CenterScreen; _browser = new ChromiumWebBrowser("about:blank"); _browser.Dock = DockStyle.Fill; // 关键：绑定必须在页面脚本执行之前完成注册 // 第三个参数在不同小版本里含义不同，先用两参数重载最保险 _browser.RegisterJsObject("hostApi", new HostApi()); _browser.LoadingStateChanged += OnLoadingStateChanged; _browser.ConsoleMessage += OnConsoleMessage; Controls.Add(_browser); // 加载本地页面或远程地址，两者写法一致 _browser.Load(Environment.GetCommandLineArgs().Length > 1 ? Environment.GetCommandLineArgs()[1] : "http://localhost:8080/index.html"); } private void OnLoadingStateChanged(object sender, LoadingStateChangedEventArgs e) { // 只在主框架加载完成时做业务动作，子 iframe 也会触发这个事件 if (!e.IsLoading && e.Browser != null && e.Browser.IsLoading == false) { BeginInvoke(new Action(() => { // 这里通常做：注入初始化脚本、隐藏滚动条、上报加载耗时 _browser.ExecuteScriptAsync( "document.body.style.overflow='hidden';"); })); } } private void OnConsoleMessage(object sender, ConsoleMessageEventArgs e) { // 把页面 console 输出转到本地日志，前端排查全靠它 System.Diagnostics.Debug.WriteLine( string.Format("[{0}:{1}] {2}", e.Source, e.Line, e.Message)); } protected override void OnFormClosing(FormClosingEventArgs e) { // 先解事件再释放，避免关闭过程中回调打到已销毁的控件上 _browser.LoadingStateChanged -= OnLoadingStateChanged; _browser.ConsoleMessage -= OnConsoleMessage; _browser.Dispose(); base.OnFormClosing(e); } } }

RegisterJsObject那一行的位置很讲究。放在构造函数里、Load之前，是因为页面里的脚本一执行就可能立刻去访问window.hostApi，晚一步注册前端就拿到 undefined。我见过把注册写在LoadingStateChanged里的写法，本地文件加载快的时候必现失败。

ConsoleMessage事件看着不起眼，实际是排查前端问题最有效的一条通道。把页面 console 的内容转成本地日志，前端同事不用装任何调试工具也能看到自己的输出。这个方法在渲染进程里触发，回调到 UI 线程时要记得用BeginInvoke包一下，直接操作控件会抛跨线程异常。

OnFormClosing里先解绑再Dispose，是为了避免关闭瞬间正好有加载回调进来。这类问题不会每次都复现，属于玄学级别，但一旦在客户现场出现就是偶发崩溃，非常难解释。

3.3 CefSettings 里我每次都会调的六个参数

参数不算多，但每一条都对应过至少一次线上问题：

CachePath还有一层用法：如果程序要同时登录多个账号，给每个账号配不同的缓存目录，Cookie、LocalStorage、IndexedDB 天然隔离，比自己在页面里清 Cookie 靠谱得多。这个技巧在第 6 章会展开。

LogSeverity给 Info 之后，日志文件会持续增长，长期运行的客户端要加个按大小轮转的清理逻辑，否则跑几个月能把磁盘塞满。我一般是在启动时判断文件超过 10MB 就重命名归档，只留最近三份。

3.4 退出流程：Cef.Shutdown 放哪一行决定进程会不会残留

Cef.Shutdown()必须在消息循环结束之后调用，也就是Application.Run返回之后。放到窗体关闭事件里、或者用Process.GetCurrentProcess().Kill()强杀，都会留下后台进程。表现是任务管理器里能看到一堆子进程挂着，用户以为程序没关干净。

正确的顺序是：窗体关闭 →ChromiumWebBrowser.Dispose()→Application.Run返回 →Cef.Shutdown()→ 进程退出。中间任何一步被跳过，都可能残留。

还有个细节：Cef.Shutdown()本身会等待子进程退出，有时间开销。如果它卡住不返回，八成是有页面还在跑长时间的 JS 或者有未完成的下载。可以在关闭前先调_browser.Stop()中断加载，把等待时间压下来。这个在客户抱怨「关窗口要等三秒」的时候特别有用。

4. C# 与页面互操作：RegisterJsObject 这条链路的完整走法

示例代码跑到这一步，页面能显示、能交互，接下来八成会被要求「页面上点个按钮，把数据存到本地数据库」。这就是 JS 与 C# 互操作的场景，也是 CefSharp 用得最多、坑最密的一块。

4.1 同步绑定与异步绑定，什么时候用哪个

CefSharp 提供两个注册入口，名字只差一个词，行为差别很大。

同步版本在页面上调用时是阻塞式的：JS 执行到调用点就停住，等 C# 方法返回结果才继续往下走。它的优点是写起来最像普通函数调用，var x = window.hostApi.getData()直接拿到返回值；缺点是如果 C# 方法里做了文件读写、数据库查询或者网络请求，整个页面会冻结，用户看到的就是「点了没反应」。

异步版本返回一个 Promise，页面不会阻塞，结果是回调拿到的。写法上稍微绕一点，但界面不会卡。

我的选择标准很直接：方法执行时间可能超过 20 毫秒的，一律用异步；纯内存计算、读个环境变量这种，用同步。判断不准的时候先用异步，不会有坏处。

还有一个约束容易被忽略：这两个注册方法都必须在页面脚本执行之前调用完成。如果页面已经加载完毕才注册，前端调用会拿到 undefined，而且不会报错，只是静默失败。

4.2 一个能直接抄的桥接类与前端调用代码

桥接类就是一个普通 C# 类，公有的实例方法会被暴露给 JS。注意是「公有实例方法」，静态方法绑不上，私有方法也绑不上，这一点跟某些人的直觉相反。

using System; using System.IO; using System.Text; namespace CefDemo { /// <summary> /// 暴露给页面脚本的宿主能力集合。 /// 只有 public 的实例方法会被绑定，静态和私有方法不可见。 /// </summary> public class HostApi { private readonly string _logPath; public HostApi() { _logPath = Path.Combine( AppDomain.CurrentDomain.BaseDirectory, "app.log"); } // 对应 JS: hostApi.getMachineCode() public string GetMachineCode() { return string.Format("{0}-{1}", Environment.MachineName, Environment.UserName); } // 对应 JS: hostApi.readConfig('serverUrl') // 返回 null 时 JS 侧拿到的是 null，不是 undefined public string ReadConfig(string key) { if (string.IsNullOrEmpty(key)) return null; var cfgFile = Path.Combine( AppDomain.CurrentDomain.BaseDirectory, "config.ini"); if (!File.Exists(cfgFile)) return null; foreach (var line in File.ReadAllLines(cfgFile, Encoding.UTF8)) { var idx = line.IndexOf('='); if (idx <= 0) continue; if (line.Substring(0, idx).Trim() == key) { return line.Substring(idx + 1).Trim(); } } return null; } // 对应 JS: hostApi.writeLog('info', '页面加载完成') // 无返回值的方法在 JS 侧得到 undefined public void WriteLog(string level, string message) { if (string.IsNullOrEmpty(message)) return; var line = string.Format("{0:yyyy-MM-dd HH:mm:ss}\t{1}\t{2}", DateTime.Now, level, message); File.AppendAllText(_logPath, line + Environment.NewLine, Encoding.UTF8); } } }

前端侧调用：

// 同步绑定：直接拿到返回值 var code = window.hostApi.getMachineCode(); console.log('机器标识：' + code); // 注意方法名大小写 // C# 的 GetMachineCode 在 JS 侧通常变成 getMachineCode // 首字母转驼峰这个行为在不同小版本里开关不一样， // 拿不准的时候两个都试一下，或者查包里的 XML 文档 var url = window.hostApi.readConfig('serverUrl'); // 无返回值的方法，同步调用返回 undefined，不要拿它做条件判断 window.hostApi.writeLog('info', '页面初始化完成');

方法名大小写是新手翻车的第一名。C# 习惯用 PascalCase，JS 习惯用 camelCase，CefSharp 在转换策略上不同小版本有差异。稳妥的做法是绑好之后先在页面里console.log(Object.keys(window.hostApi))打一遍，看到底暴露成什么样，别靠猜。

异步版本写法不一样，页面侧拿到的是 Promise：

// 注册方式换成 _browser.RegisterAsyncJsObject("hostApi", new HostApi()) window.hostApi.readConfig('serverUrl') .then(function (url) { // 这里拿到的才是真正的返回值 document.getElementById('frame').src = url; }) .catch(function (err) { console.error('读取配置失败', err); });

我一般把读配置、查数据库这类操作全部做成异步。同步版本在查询稍慢的时候会让整个页面卡住，用户以为程序死了，会反复点击，然后触发一堆重复请求，问题越滚越大。

4.3 传参类型的边界：哪些值能过，哪些会变成 undefined

JS 和 C# 之间要跨进程序列化，不是所有类型都能原样过去。这块边界踩过一次就能记住：

自定义类返回给前端是失败率最高的一项。看起来能拿到一个对象，实际属性全是 undefined，因为跨进程只传了类型名没有传字段值。稳妥做法是返回Dictionary<string, object>，或者在 C# 侧自己序列化成 JSON 字符串，前端JSON.parse一次。

参数方向也有开销。传一个几兆的字符串进去，序列化和跨进程拷贝要几十毫秒，频繁调用会明显拖慢页面。大块数据别走这条通道，改成页面发一个 ID 过来，C# 这边自己去读文件或者查库。

还有一点：桥接方法在渲染进程看是同步的，实际执行在浏览器主进程，也就是 UI 线程。方法里做耗时操作会直接卡住界面，跟直接在按钮事件里写Thread.Sleep是一个效果。需要真正耗时的处理时，桥接方法里只负责派发任务，结果通过ExecuteScriptAsync回推给页面。

5. 排查清单：白屏、闪退、找不到 DLL、绑定失效的五个真实坑

下面这五条是我在 .NET 4.0 + VS2010 组合上反复遇到的，按出现频率排。

坑一：编译通过，一运行就抛 BadImageFormatException 或找不到 libcef.dll。现象是双击 exe 直接弹异常框，堆栈指向 CefSharp.Core 的静态构造。原因是进程位数和原生 DLL 位数不匹配——AnyCPU 在 64 位系统上按 64 位跑，加载的却是 32 位 libcef.dll。解决是回到 2.3 节，把 PlatformTarget 显式写成 x86，并确认输出目录是bin\x86\Debug而不是bin\Debug。改完记得清理一次重新生成，老的 DLL 会残留在输出目录里骗人。

坑二：窗口出来了，内容区一片白，日志里什么也没有。原因通常有两个：GPU 合成在虚拟机或远程会话下失败；或者缓存目录没有写权限。先在初始化里加disable-gpu和disable-gpu-compositing两个命令行参数，再看cef.log里有没有 GPU 进程相关的警告。如果日志本身都没生成，那就是LogFile的路径不可写，把CachePath和LogFile都挪到程序目录下再试。

坑三：页面上调用桥接方法，报对象不存在或者永远返回 undefined。三种可能：注册时机晚于页面脚本执行；方法名大小写在 JS 侧被转换了；子进程可执行文件没找到导致绑定链路断掉。排查顺序是从后往前——先在输出目录确认CefSharp.BrowserSubprocess.exe存在且BrowserSubprocessPath指对了，再在页面里console.log(Object.keys(window.hostApi))确认实际暴露的名字，最后检查注册代码是不是放在了构造函数里。

坑四：关掉窗体后任务管理器里还有一堆进程挂着。原因是Cef.Shutdown()没被调用，或者调用位置不对。常见错误是把Shutdown写在窗体的FormClosed里，那时候消息循环还没退出，Chromium 的子进程收不到退出信号。正确做法是放在Application.Run返回之后。另外如果关闭时页面正在跑长任务，Shutdown会等待，表现是关窗口卡几秒，可以先Stop()再关。

坑五：Debug 配置下正常，切到 Release 就崩。大概率是 Release 的输出目录里缺原生文件。老版本的 NuGet targets 在部分配置下复制行为不一致，尤其是手工改过OutputPath之后。解决是直接去 Release 输出目录列一遍文件，对照下面这张清单逐个核对：

核对完把缺的补上，并且在 csproj 里加一条生成后事件做自动复制，别指望每次手工补。

6. 从能跑到好用：把内嵌浏览器当成业务容器来配

示例代码跑通只是起点。真正投到业务里，还要处理下载、打印、多账号、内存这几件事。这一层没有标准答案，我给的是自己项目里验证过的一组做法。

下载默认是不处理的，点了没反应。要接管得实现IDownloadHandler，在OnBeforeDownload里拿到建议文件名，在OnDownloadUpdated里更新进度。我一般会把它接到界面上的一个进度条，用户至少知道在下载。打印这块，页面里直接调window.print()会弹 Chromium 自己的打印对话框，如果业务要的是静默打印到指定打印机，就得走 C# 侧的PrintToPdf先生成文件再交给系统打印队列。

多账号隔离用缓存目录最省事。给每个账号算一个稳定的哈希值，拼成cef_cache\{hash}传给CachePath，Cookie、LocalStorage 全部天然隔离，不用在页面里写任何清理逻辑。代价是磁盘占用翻倍，长期运行要加个清理策略，把超过 30 天没登录过的目录删掉。

内存方面，x86 进程上限 2GB 是硬约束。页面复杂、开着 DevTools、又加载了大图的时候，很容易顶到上限然后整个进程被杀。我的做法是：默认关闭 DevTools，只在配置文件里开一个调试开关；页面切换到后台时调SetZoomLevel之外再执行一段释放图片缓存的脚本；长时间不操作的实例定时重建一次ChromiumWebBrowser。最后这一条听起来暴力，但在需要连续开机几周的客户端上，比重构内存泄漏划算得多。

快捷键也值得单独处理。F5 刷新、Ctrl+加号缩放、F12 开调试，这些在浏览器里天经地义，在内嵌容器里往往要按业务需要裁剪。我一般重写ProcessCmdKey，把用不上的组合键吞掉，避免用户误触把页面刷没了，正在填的表单直接丢失。

最后说个我自己的习惯：每接一个新项目，先把第 5 章那张文件清单打印出来贴在显示器边上，第一次部署到客户机器时逐个打勾。这套组合的坑九成集中在部署环节，代码本身反而没那么多花样。版本卡准、平台锁死、文件齐全，剩下的就是业务逻辑的事了。希望帮到你。

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