简介这份资源面向使用 C# 进行 Web 自动化与多账号管理的开发者基于 CEFSharp 封装 Chromium 浏览器引擎重点解决多账号同时登录、Cookie 隔离与浏览器指纹修改三大问题。包内通过为每个账号创建独立 ChromiumWebBrowser 实例并绑定独立 IRequestContext实现 Cookie 存储互不干扰同时演示了借助 JavaScript 注入调整 UserAgent、Accept-Language 等头部信息以及结合第三方库混淆浏览器指纹的思路并延伸至自动加购与反爬虫策略的工程实践。资源共 873 个文件以 344 个 cs 源码、43 个 cpp、114 个 h 头文件为核心辅以 52 个 dll、174 个 pak 资源包及 xml、resx、config 等配置项压缩包约 376.59MB结构完整可直接编译运行。目前已有 4446 人学习下载适合具备一定 C# 与浏览器自动化基础、希望深入掌握多账号隔离与匿名化方案的开发者参考。1. 多账号同时在线为什么 CefSharp 默认做不到做过桌面端自动化的人多半遇到过这个场景同一台机器上要同时挂三个、五个甚至更多账号每个账号各自登录、各自保持会话互不串味。用 CefSharp 起一个 Chromium 内核的浏览器控件很容易但一旦你 new 出第二个 ChromiumWebBrowser就会发现两个窗口共享了同一份 Cookie、同一份 LocalStorage、同一份缓存目录——A 账号刚登录B 账号刷新一下也变成已登录状态这就是典型的会话污染。根子在于 CefSharp 默认使用全局的CefSettings所有 Browser 实例共用同一个CachePath和同一个user-data-dir。Chromium 本身是支持多 Profile 的只是 CefSharp 的封装把这条路藏得比较深。要真正做到多账号同时登陆核心是三件事给每个账号分配独立的请求上下文RequestContext、在上下文级别做 Cookie 隔离、再顺手把几个容易暴露的浏览器指纹参数改掉。这篇笔记就按这个顺序把能直接抄的代码、参数含义和踩过的坑一次讲清楚适合正在做多账号桌面工具、又不想每个账号开一台虚拟机的开发者。2. 用 RequestContext 做 Cookie 隔离从全局到按账号分仓2.1 为什么必须走 RequestContext 而不是清 Cookie很多人第一反应是「登录前调一次CookieManager.DeleteCookiesAsync不就行了」。这个思路在单账号串行场景能跑但多账号同时在线必然翻车账号 A 正在轮询接口账号 B 触发了一次清 CookieA 的会话当场失效。Cookie 是挂在请求上下文上的状态不是挂在窗口上的靠「用完就清」这种时间片轮转的方式本质上是在跟并发抢状态。CefSharp 从较新的版本开始暴露了IRequestContext它对应 Chromium 的network::mojom::URLLoaderFactory那一层每个 RequestContext 拥有独立的 Cookie 存储、独立的缓存、独立的代理设置。你给每个账号创建一个 RequestContext就等于给每个账号开了一个逻辑上独立的浏览器 Profile它们之间天然不共享任何会话数据。这是唯一干净的做法也是后面所有指纹隔离的前提。2.2 创建独立 RequestContext 的最小代码下面这段是核心骨架注意RequestContextSettings里的CachePath必须每个账号不同否则 Chromium 会在磁盘层面复用缓存目录Cookie 隔离会失效。using CefSharp; using CefSharp.OffScreen; // 或 CefSharp.WinForms / Wpf using System; using System.IO; public class AccountBrowser : IDisposable { private ChromiumWebBrowser _browser; private IRequestContext _context; private string _accountId; public AccountBrowser(string accountId, string rootDir) { _accountId accountId; // 每个账号一个独立缓存目录路径里带上账号标识 var cachePath Path.Combine(rootDir, profiles, accountId, cache); Directory.CreateDirectory(cachePath); var settings new RequestContextSettings { CachePath cachePath, PersistSessionCookies true, // 会话 Cookie 落盘重启后仍在线 PersistUserPreferences true, AcceptLanguageList zh-CN,zh;q0.9,en;q0.8 }; // 关键用 CreateRequestContext 而不是全局上下文 _context Cef.GetGlobalRequestContext(); // 占位见下方说明 _context CreateContext(settings); _browser new ChromiumWebBrowser(about:blank, _context); } private IRequestContext CreateContext(RequestContextSettings settings) { // CefSharp 提供同步创建接口返回已初始化的上下文 return CefSharp.Cef.GetGlobalRequestContext() null ? throw new InvalidOperationException(Cef 未初始化) : RequestContextFactory.Create(settings); } public void Dispose() { _browser?.Dispose(); _context?.Dispose(); } }逻辑说明RequestContextSettings.CachePath是隔离的物理基础两个账号指向同一个目录时Chromium 的 Cookie 数据库Cookies文件会被两个上下文同时打开行为不可预期。PersistSessionCookies true决定会话级 Cookie 是否写盘做「记住登录」必须开。AcceptLanguageList顺手设成中文优先避免默认 en-US 在部分站点触发风控。参数说明CachePath建议放在用户目录下的独立子目录不要放程序安装目录可能无写权限。PersistUserPreferences控制是否持久化用户偏好多账号场景建议开否则每次启动都要重新设语言、缩放等。RequestContextFactory.Create是同步的必须在 Cef 初始化完成之后调用否则会抛异常。2.3 把 Cookie 读写锁在各自的上下文里创建完上下文只是第一步真正操作 Cookie 时要确保用的是这个账号自己的ICookieManager而不是全局那个。public async Task SetLoginCookieAsync(string url, string name, string value) { // 从当前账号的上下文拿 CookieManager而不是 Cef.GetGlobalCookieManager() var cookieManager _context.GetCookieManager(null); var cookie new Cookie { Name name, Value value, Domain new Uri(url).Host, Path /, Expires DateTime.Now.AddDays(7), HttpOnly true, Secure url.StartsWith(https, StringComparison.OrdinalIgnoreCase) }; await cookieManager.SetCookieAsync(url, cookie); } public async Taskstring GetCookieValueAsync(string url, string name) { var cookieManager _context.GetCookieManager(null); var cookies await cookieManager.GetCookiesAsync(url); foreach (var c in cookies) { if (c.Name name) return c.Value; } return null; }逻辑说明_context.GetCookieManager(null)里的null表示使用该上下文默认的 Cookie 存储不要传全局的Cef.GetGlobalCookieManager()否则又回到共享状态。SetCookieAsync的url参数决定 Cookie 归属的域写错域会导致 Cookie 存进去但请求时带不上。参数说明HttpOnly对登录态 Cookie 建议开防止页面脚本读取Secure只在 https 下为 truehttp 站点设了会导致 Cookie 被丢弃。Expires设成过去时间等于删除该 Cookie做登出时可以用这个技巧。3. 修改浏览器指纹哪些参数值得改哪些改了反而露馅3.1 指纹隔离的边界只改会被服务端校验的项浏览器指纹是个大话题但做多账号工具时没必要全改。真正会被服务端拿来做关联的通常是 User-Agent、时区、语言、屏幕分辨率、WebGL 渲染器、Canvas 哈希这几类。改得越多越容易自相矛盾——比如你把 UA 改成 macOS但navigator.platform还是 Win32这种不一致反而比不改更容易被识别。我的原则是只改那些「账号之间必须不同、且改完内部自洽」的项。UA 和时区是性价比最高的两个WebGL 和 Canvas 属于进阶改不好会引入新的可识别特征。3.2 用 RequestHandler 注入自定义 UA 和请求头CefSharp 允许在请求发起前拦截并修改请求头这是改 UA 最稳的位置比在页面里用 JS 覆盖navigator.userAgent更底层。public class FingerprintRequestHandler : RequestHandler { private readonly string _userAgent; private readonly string _acceptLanguage; public FingerprintRequestHandler(string userAgent, string acceptLanguage) { _userAgent userAgent; _acceptLanguage acceptLanguage; } protected override void OnBeforeBrowse( IWebBrowser browserControl, IBrowser browser, IFrame frame, IRequest request, bool userGesture, bool isRedirect) { // 只处理主框架避免 iframe 重复改写 if (frame.IsMain) { request.SetHeaderByName(User-Agent, _userAgent, true); request.SetHeaderByName(Accept-Language, _acceptLanguage, true); } base.OnBeforeBrowse(browserControl, browser, frame, request, userGesture, isRedirect); } }逻辑说明OnBeforeBrowse在导航发起前触发此时改请求头能影响服务端收到的内容。SetHeaderByName第三个参数overwrite true表示覆盖已有值不覆盖的话可能被默认 UA 顶掉。只对frame.IsMain生效是为了避免子框架请求头被反复改写导致行为异常。参数说明_userAgent建议每个账号从一组真实浏览器 UA 里随机取不要自己拼一个不存在的版本号。_acceptLanguage要和CefSettings.AcceptLanguageList保持一致否则请求头和navigator.language对不上。3.3 时区和屏幕参数在页面加载前注入时区这类参数没法通过请求头改得在页面脚本执行前注入。CefSharp 提供OnFrameLoadStart或EvaluateScriptAsync的时机控制但更稳的是用CefSharp.DevTools或直接在OnContextCreated里注入。public class TimezoneInjector : RequestHandler { private readonly string _timezoneId; public TimezoneInjector(string timezoneId) { _timezoneId timezoneId; } protected override void OnContextCreated( IWebBrowser browserControl, IBrowser browser, IFrame frame, IJsObject jsObject) { if (!frame.IsMain) return; // 覆盖 Intl 的时区解析让页面拿到的时区和账号绑定 var script $ (function() {{ var origResolved Intl.DateTimeFormat.prototype.resolvedOptions; Intl.DateTimeFormat.prototype.resolvedOptions function() {{ var opts origResolved.call(this); opts.timeZone {_timezoneId}; return opts; }}; var origOffset Date.prototype.getTimezoneOffset; Date.prototype.getTimezoneOffset function() {{ return {GetOffsetMinutes(_timezoneId)}; }}; }})(); ; frame.ExecuteJavaScriptAsync(script); } private int GetOffsetMinutes(string tz) { // 简化示例实际应根据时区 ID 计算这里返回东八区偏移 return -480; } }逻辑说明OnContextCreated在每个 frame 的 JS 上下文创建后、页面脚本执行前触发是注入覆盖逻辑的最佳时机。覆盖Intl.DateTimeFormat.prototype.resolvedOptions能骗过大多数通过Intl检测时区的脚本覆盖getTimezoneOffset则处理老式检测。参数说明_timezoneId用 IANA 时区名如Asia/Shanghai不要用GMT8这种部分库不认。GetOffsetMinutes返回的是「本地时间与 UTC 的分钟差」注意符号东八区是 -480不是 480写反了时区会差 16 小时。4. 多账号并发时的资源与生命周期管理4.1 每个账号一个 Browser 实例别复用有人为了省内存想用一个 Browser 实例切换 RequestContext 来模拟多账号。这条路走不通Chromium 的 Browser 和 RequestContext 在创建时就绑定了运行期换上下文会导致渲染进程状态错乱。正确做法是每个账号一个ChromiumWebBrowser各自持有自己的IRequestContext。内存开销确实存在一个 OffScreen 的 Browser 大概几十到一百多 MB取决于页面复杂度。如果账号数量超过十个建议做「活跃账号常驻、非活跃账号挂起」的策略把不操作的 Browser 的RequestContext保留Cookie 还在但销毁 Browser 实例需要时再重建并复用同一个上下文。4.2 上下文复用与销毁的时机public class AccountPool : IDisposable { private readonly Dictionarystring, IRequestContext _contexts new(); private readonly string _rootDir; public AccountPool(string rootDir) { _rootDir rootDir; } public IRequestContext GetOrCreateContext(string accountId) { if (_contexts.TryGetValue(accountId, out var ctx)) return ctx; var cachePath Path.Combine(_rootDir, profiles, accountId, cache); Directory.CreateDirectory(cachePath); var settings new RequestContextSettings { CachePath cachePath, PersistSessionCookies true }; var newCtx RequestContextFactory.Create(settings); _contexts[accountId] newCtx; return newCtx; } public void Dispose() { foreach (var ctx in _contexts.Values) ctx.Dispose(); _contexts.Clear(); } }逻辑说明上下文可以跨 Browser 实例复用只要CachePath不变Cookie 就一直在。销毁 Browser 时不要顺手 Dispose 上下文否则 Cookie 会随上下文一起释放如果没开持久化。AccountPool统一管理上下文生命周期避免重复创建导致同一个 CachePath 被多个上下文打开。参数说明_rootDir建议放在%LocalAppData%下避免权限问题。PersistSessionCookies开了之后即使上下文 DisposeCookie 也已落盘下次用同一个 CachePath 创建上下文还能恢复。4.3 并发数量与线程模型CefSharp 的 Browser 实例必须在 UI 线程创建但 RequestContext 可以在任意线程创建只要 Cef 已初始化。多账号并发时建议把 Browser 创建操作 marshal 回 UI 线程Cookie 读写这类异步操作则可以在后台线程发起。并发数量上Chromium 每个 Browser 会占用独立的渲染进程默认 site-per-process账号多了内存和 CPU 都会吃紧。实测在普通开发机上同时活跃 5 到 8 个账号比较稳再多就要考虑分批或降低页面复杂度。如果只是保持登录态、偶尔轮询接口用 OffScreen 模式比 WinForms 模式省资源。5. 避坑与排查多账号隔离最容易翻车的五个点5.1 现象两个账号 Cookie 互相覆盖原因RequestContextSettings.CachePath指向了同一个目录或者代码里误用了Cef.GetGlobalCookieManager()。Chromium 的 Cookie 数据库是文件锁定的两个上下文打开同一个文件时写入行为不可预期表现为「后写的覆盖先写的」。解决检查每个账号的CachePath是否唯一可以在路径里拼账号 ID 的哈希。全局搜索代码里所有GetGlobalCookieManager调用全部替换成_context.GetCookieManager(null)。5.2 现象改了 UA 但服务端还是识别出真实环境原因只改了请求头 UA没改navigator.userAgent或者改了navigator.userAgent但请求头没改两者不一致。部分站点会同时校验请求头和 JS 读到的值对不上就判定为异常。解决请求头用OnBeforeBrowse改JS 侧用OnContextCreated覆盖navigator.userAgent的 getter确保两处值完全一致。注意navigator.userAgent是只读属性要用Object.defineProperty重定义。5.3 现象时区改了但Date对象还是本地时间原因只覆盖了Intl.DateTimeFormat没覆盖Date.prototype.getTimezoneOffset或者覆盖时机太晚页面脚本已经执行过了。解决确保注入在OnContextCreated里完成且同时覆盖Intl和Date两条路径。测试时在页面控制台执行new Date().getTimezoneOffset()和Intl.DateTimeFormat().resolvedOptions().timeZone交叉验证。5.4 现象账号多了之后程序卡死或崩溃原因Browser 实例创建过多渲染进程耗尽内存或者上下文 Dispose 时还有未完成的请求导致资源释放异常。解决限制同时活跃的 Browser 数量非活跃账号只保留上下文不保留 Browser。Dispose 前先调browser.Stop()停止加载再 Dispose。监控CefSharp的CefSettings里WindowlessRenderingEnabled等参数OffScreen 模式下适当降低渲染帧率。5.5 现象重启程序后登录态丢失原因PersistSessionCookies没开或者CachePath每次启动都变了比如用了临时目录。解决PersistSessionCookies trueCachePath用固定路径。验证方法登录后关闭程序检查CachePath下是否有Cookies文件有则说明落盘成功。注意部分站点的登录态是 Session Cookie不设Expires这种必须靠PersistSessionCookies才能持久化。6. 进阶用 DevTools 协议做指纹一致性校验前面改的 UA、时区、语言都是「点」上的修改真正难的是让这些点互相自洽。一个实用的验证手段是接 CefSharp 的 DevTools 协议在页面加载后自动跑一段检测脚本把关键指纹项读出来做交叉比对。public async TaskDictionarystring, string CollectFingerprintAsync( ChromiumWebBrowser browser) { var script (function() { var result {}; result.userAgent navigator.userAgent; result.platform navigator.platform; result.language navigator.language; result.languages (navigator.languages || []).join(,); result.timezone Intl.DateTimeFormat().resolvedOptions().timeZone; result.offset new Date().getTimezoneOffset(); result.screen screen.width x screen.height; result.colorDepth screen.colorDepth; result.hardwareConcurrency navigator.hardwareConcurrency; result.deviceMemory navigator.deviceMemory || unknown; return JSON.stringify(result); })(); ; var response await browser.EvaluateScriptAsync(script); if (response.Success response.Result is string json) { return System.Text.Json.JsonSerializer .DeserializeDictionarystring, string(json); } return new Dictionarystring, string(); }逻辑说明EvaluateScriptAsync在页面上下文执行脚本并返回结果适合做加载后的自检。把结果序列化成 JSON 再解析避免直接处理JavascriptResponse的嵌套对象。这段脚本读的都是最常被风控采集的项跑一遍就能看出账号之间是否真的隔离干净。参数说明navigator.deviceMemory不是所有环境都有做兜底处理。hardwareConcurrency反映 CPU 核心数如果所有账号都返回同一个值说明没做隔离——但这个值本身不建议乱改改了容易和实际性能表现矛盾通常保持真实即可只要账号之间不要求不同。我一般会在每个账号首次登录后跑一次这个采集把结果存下来后续如果出现「某个账号突然被要求验证」就对比它和正常账号的指纹差异往往能定位到是哪个参数没隔离干净。这套自检脚本帮我省过好几次通宵排查比盲猜靠谱得多。最后一个习惯改指纹参数时一次只改一项改完立刻用上面的脚本验证确认自洽了再改下一项。一次性改一堆然后发现出问题根本不知道是哪一项引起的这种血泪经验踩过一次就够了。希望帮到你。本文还有配套的精品资源点击获取