CEFCore 默认使用 CEF 自带的据库 SQLite 实现来管理 Cookie、LocalStorage 等本地数据。据库但如果你在 .NET 项目里集成了 CEFSharp，据库有时候会遇到一个尴尬的据库情况：CEF 内置的 SQLite 版本和你项目里引用的 System.Data.SQLite 或 Microsoft.Data.Sqlite 版本冲突。典型症状是据库程序启动时直接抛 SQLite Error 14 或者 Unable to load DLL 'sqlite3'，甚至更隐蔽的据库——数据写入看似成功，读出来却是据库乱码。

我去年做一个桌面客户端时就踩了这个坑。据库项目里用 EF Core + SQLite 存业务数据，据库同时用 CEFSharp 加载网页。据库单独跑都没问题，据库合到一起就崩。据库排查了半天，据库发现是据库 CEF 的 libcef.dll 自带了一个 sqlite3 的导出符号，而 System.Data.SQLite 也带了一个，据库两者加载顺序不同，谁先谁后决定了用哪个版本，结果就是随机性崩溃。

解决办法只有一个：让 CEFCore 不再使用内置 SQLite，而是切换到我们指定的、和项目其他部分一致的 SQLite 动态库。CEF 本身提供了命令行开关 --sqlite-dll-path，但 CEFSharp 没有直接暴露这个参数。需要手动在初始化 CEF 之前，往 CefSettings 的 CommandLineArgs 里塞进去。

具体做法是这样：先确认你项目里用的 SQLite 原生库路径。比如 NuGet 包 Microsoft.Data.Sqlite 会把 e_sqlite3.dll 放在输出目录的 runtimes/win-x64/native/ 下。然后构造 CEF 的启动参数：

var settings = new CefSettings(); settings.CommandLineArgs.Add("sqlite-dll-path", Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "runtimes", "win-x64", "native", "e_sqlite3.dll")); Cef.Initialize(settings);

这里有个细节：CEF 要求的 SQLite 动态库必须导出标准的 C 接口符号，比如 sqlite3_open、sqlite3_prepare_v2 这些。e_sqlite3.dll 是 SQLite 官方源码编译的，符号完全匹配，所以能直接用。但如果你用的是 System.Data.SQLite 的 SQLite.Interop.dll，它导出的符号名可能带前缀或版本后缀，CEF 就认不出来，会报 sqlite3_open not found。所以优先选 e_sqlite3.dll 或者自己从 sqlite.org 下载源码编译一个干净的版本。

另一个坑是路径中的反斜杠。CEF 的命令行参数解析对 Windows 路径里的 \ 处理不太一致，有时候会把 \n 当成换行。稳妥的做法是全部换成正斜杠 /，或者用 Path.GetFullPath 之后再 Replace('\\', '/')。我一开始没注意，结果 CEF 去加载了一个叫 C:Users 的奇怪路径，自然失败。

切换之后，CEF 的 Cookie 和 LocalStorage 依然正常工作，但底层用的就是你指定的那个 SQLite 版本了。这样整个进程里只有一个 SQLite 实现，版本冲突消失。我那个项目改完之后，连续跑了一周没再出现崩溃。

还有一点值得提：CEF 在 Windows 上默认会从自己所在目录找 libcef.dll，而 sqlite-dll-path 是相对路径解析的。如果你传的是相对路径，它会相对于 libcef.dll 所在目录去找，而不是你的工作目录。所以要么传绝对路径，要么把 SQLite 动态库复制到 CEF 的 Release 或 Debug 文件夹旁边。我选择传绝对路径，省事。

最后说一个观察：CEF 的 --sqlite-dll-path 这个开关在官方文档里几乎找不到，只在源码的 content_switches.cc 里有定义。CEFSharp 的 issue 列表里有人提过，但回答大多是“用默认的就行”。可现实是，只要你的 .NET 项目里同时用了其他 SQLite 库，默认的就会出问题。所以这个冷门参数值得记下来。

(责任编辑：探索)