简介面向需要在 VS2010 与 .NET Framework 4.0 环境中嵌入 Chromium 浏览器的 C# WinForm 开发者这套 189.28MB 的资源包包含 319 个文件核心是可运行的 CefSharp.WinForms 49.0.1 示例源码以及配套的 Chromium 内核运行库。文件以 pak、dll 等原生组件为主辅以 cs 源码、xml 配置、exe 可执行文件与 pdb 调试符号压缩为 rar 格式解压后可直接打开解决方案并运行。示例从添加 CefSharp 引用、初始化 Cef 环境到创建 ChromiumWebBrowser 控件、处理加载完成与状态变更事件再到执行 JavaScript 和自定义缓存路径、禁用 GPU 等设置均有完整演示适合动手跟做。资源目前已吸引 3430 人浏览学习对于想快速在 WinForm 项目中获得 Chrome 内核体验的开发者是一份可直接落地的参考实现也能帮助理解 Cef 生命周期管理。1. CefSharp.Winform 示例项目VS2010 老工程也能塞进一个现代 Chromium 内核接手过老系统的开发者应该都有这种体验WinForm 里要显示网页第一反应是拖一个系统自带的 WebBrowser 控件可那玩意是 IE 内核渲染新页面经常白屏错位flex 布局直接稀烂CSS 动画卡成 PPT。这个 C# WinForm 工程给的是另一条路用 CefSharp.Winform 把 Chromium 内核嵌进窗体整套示例基于 VS2010 和 .NET 4.0 搭建专门照顾还跑在老工具链上的维护型项目。工程里包含从 Cef 初始化、浏览器控件创建、页面加载到 C# 与 JavaScript 双向通信的完整示例代码拿到就能编译。适合两类人一是要把老系统里内嵌 IE 页面的模块替换成 Chromium 内核的维护者二是刚接触 CefSharp、想知道这个组件在 WinForm 里怎么跑起来、网页怎么反过来调用本地 C# 方法的开发者。看完这篇你能照着手里的源码一步步把它跑起来再动手改成自己的浏览器壳。2. 环境准备与项目骨架.NET 4.0 下的依赖匹配是第一步2.1 为什么选 CefSharp三个内嵌方案的取舍老系统里给 WinForm 塞浏览器的方案常见就三种系统自带的 WebBrowser 控件、WebKit.NET、CefSharp。WebBrowser 本质是 IE 内核的封装部署最省事但渲染能力和系统 IE 版本强绑定遇到 ES6 语法、H5 视频、CSS Grid 这些现代特性基本没救WebKit.NET 项目早就停更社区里连个修 bug 的人都没有CefSharp 则是把 CEFChromium Embedded Framework封装成 .NET 控件WinForm 和 WPF 都有对应包内核是完整 Chromium页面兼容性跟现代浏览器一致。这个示例选 CefSharp.WinForms 而不是 WPF 版就是因为老工程几乎全是 WinForm迁移成本最低。这里有个非常容易忽略的点CefSharp 的新版本早就放弃 .NET 4.0 了高版本包要求 .NET Framework 4.5.2 起步。所以这个示例工程里引用的必然是当年兼容 .NET 4.0 的那个版本分支。你如果手痒用 NuGet 重新装最新稳定版大概率编译直接挂要么 API 对不上要么程序集加载失败。我一般的做法是把包里自带的 DLL 整个拷出来用“添加引用 → 浏览”指向本地程序集而不是走 NuGet这样版本完全可控换一台机器也不会被自动升级坑到。下面这个表是三种方案的横向对比方便你判断自己的场景该不该换。方案内核现代页面兼容性维护状态备注WebBrowser 控件IE差系统自带长期可用老系统里最普遍却最让人头疼WebKit.NETWebKit一般已停更出问题没人管CefSharp.WinFormsChromium好活跃老版本仍需手动锁版本2.2 工程结构与关键文件清单拿到示例工程后先别急着编译打开项目把结构过一遍。典型的 CefSharp.WinForm 工程长这样CefSharpWinFormDemo.sln ├─ CefSharpWinFormDemo\ │ ├─ Program.cs // 入口Cef.Initialize 启动主窗体 Cef.Shutdown │ ├─ MainForm.cs // 主窗体创建浏览器控件、处理事件、双向调用示例 │ ├─ MainForm.Designer.cs // 窗体设计器生成的布局代码 │ ├─ JsBoundObject.cs // 注册给 JavaScript 调用的 .NET 对象 │ └─ packages.config // 依赖包清单 └─ packages\ // 本地包缓存DLL 都在这里其中 Program.cs 是命脉Cef 初始化和关闭都在这里MainForm.cs 是主战场浏览器控件从创建到交互的代码全在JsBoundObject.cs 是桥接层专门放暴露给网页的 C# 方法。编译输出目录里还有一批运行时文件它们是 CefSharp 能在你机器上跑起来的物理基础bin\Debug\ ├─ CefSharp.dll // 托管封装.NET 代码直接引用 ├─ CefSharp.Core.dll // 核心互操作层 ├─ CefSharp.WinForms.dll // WinForm 控件实现 ├─ libcef.dll // CEF 的 C 接口层体积最大 ├─ icudtl.dat // ICU 国际化数据缺了直接崩 ├─ cef.pak // 资源包 ├─ devtools_resources.pak // 开发者工具资源 ├─ locales\ // 各国语言包至少留 zh-CN 和 en-US └─ swiftshader\ // 软件渲染相关低配机器上靠它兜底CefSharp.dll 是托管层libcef.dll 是内核入口两者缺一不可locales 和 .pak 这类资源文件看着不起眼少了某一个浏览器控件就可能白屏。这个文件清单建议截图存着后面排查问题全靠它。2.3 引用配置与首跑检查清单在 VS2010 里打开工程先做三件事。第一打开“生成 → 配置管理器”把活动解决方案平台设为 x86这一步决定你编译出来的是什么位数第二展开项目引用确认 CefSharp、CefSharp.Core、CefSharp.WinForms 三项都在并且“复制本地”属性为 True第三确认目标框架是“.NET Framework 4”而不是“4.0 Client Profile”——后者是个经典陷阱新工程的默认值就是 Client ProfileCefSharp 依赖的部分程序集在精简版里根本不存在编译到一半报“找不到程序集”别觉得莫名其妙。这三步做完再点生成。如果输出目录里多个子文件夹自动冒出来说明复制本地的配置生效了。我习惯首跑前看一眼 bin\Debug 下有没有 locales 目录没有就手动从 packages 里拷一份别等运行时白屏了才回头找原因。平台位数这件事多说一句CEF 的 libcef.dll 分 x86 和 x64 两个版本这个示例锁定 x86你就老老实实按 x86 编别想着 AnyCPU 自动适配AnyCPU 在 64 位系统上会去加载 x64 的本地 DLL而你的引用还是 x86 的启动必炸。3. 核心模块拆解从 Cef.Initialize 到 JS 回调的完整链路3.1 入口初始化Cef.Initialize 的调用时机与参数所有 CefSharp 程序的起点都在 Program.cs。Cef.Initialize 是整个 CEF 生命周期的开关必须在创建任何 ChromiumWebBrowser 实例之前调用顺序反了直接异常。示例里的写法大概是这样的// Program.cs using System; using System.Windows.Forms; using CefSharp; using CefSharp.WinForms; namespace CefSharpWinFormDemo { static class Program { [STAThread] static void Main() { var settings new CefSettings { // 缓存目录建议用绝对路径开发期方便清理 CachePath Application.StartupPath \cache, // 界面语言 Locale zh-CN, // 需要远程调试页面时打开默认注释 // RemoteDebuggingPort 9222, }; // 第二个参数 performDependencyCheck 会检查 libcef.dll 等依赖 Cef.Initialize(settings, performDependencyCheck: true, browserProcessHandler: null); Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new MainForm()); // 退出前必须关停 Cef否则浏览器子进程会残留 Cef.Shutdown(); } } }逻辑说明CefSettings 是初始化参数的集中地CachePath 如果不给CEF 会往临时目录写缓存重装系统后缓存清空页面加载速度明显变慢Locale 决定浏览器控件的 UI 语言同时也影响网页里 navigator.language 的值。performDependencyCheck 传 true 时初始化阶段会检查 libcef.dll、icudtl.dat 等关键文件是否存在缺了直接抛异常这比运行时白屏好排查得多。参数说明CefSettings 里还有 LogFile 和 LogSeverity 两个常用项排查问题时把 LogFile 指到一个固定路径LogSeverity 设为 VerboseCEF 会输出非常详细的日志定位白屏和崩溃全靠它。注意 Initialize 和 Shutdown 必须配对调用且都在主线程Shutdown 之后再创建浏览器实例会直接抛 ObjectDisposedException。很多新手把 Shutdown 写进 FormClosed 事件结果主程序退出时 UI 线程已经收尾反而触发新的异常。3.2 浏览器控件的创建与生命周期事件主窗体的工作就是把 ChromiumWebBrowser 当成一个普通 Control 塞进窗体这个控件继承自 Control支持 Dock、Anchor、事件用起来跟 PictureBox 差不多。示例里核心代码是这样的// MainForm.cs 关键片段 using CefSharp; using CefSharp.WinForms; public partial class MainForm : Form { private ChromiumWebBrowser _browser; public MainForm() { InitializeComponent(); // 构造函数里直接传初始地址 _browser new ChromiumWebBrowser(https://example.com/page); _browser.Dock DockStyle.Fill; this.Controls.Add(_browser); // 地址变化事件同步到地址栏 _browser.AddressChanged OnAddressChanged; // 加载状态变化事件用于判断页面是否加载完成 _browser.LoadingStateChanged OnLoadingStateChanged; } private void OnAddressChanged(object sender, AddressChangedEventArgs e) { // CEF 有自己的线程跨线程更新控件必须 Invoke if (this.txtAddress.InvokeRequired) { this.txtAddress.Invoke(new Action(() this.txtAddress.Text e.Address)); return; } this.txtAddress.Text e.Address; } private void OnLoadingStateChanged(object sender, LoadingStateChangedEventArgs e) { // IsLoading 为 false 表示页面主框架加载完成 if (!e.IsLoading) { // 此时可以安全地注入脚本或读取页面状态 } } }逻辑说明ChromiumWebBrowser 构造时传的地址会在内部异步加载不需要手动调用 LoadDock.Fill 让它铺满窗体配合一个顶部工具栏就是最简浏览器壳。AddressChanged 事件在 CEF 的 UI 线程触发直接给 WinForm 控件赋值会跨线程所以先用 InvokeRequired 判断再通过 Invoke 回到 UI 线程这是 WinForm 多线程的铁律CefSharp 尤其敏感。LoadingStateChanged 会触发多次主框架开始加载、子框架加载、加载完成、加载失败都会进来。判断 !e.IsLoading 只是“某一次加载结束”的信号严格说还要配合 frame 判断示例里用来做“页面加载完再注入脚本”的时机是够的。如果你发现脚本有时执行有时不执行多半是没等这个事件就抢跑注入。3.3 C# 主动调用页面里的 JavaScript从 C# 往页面推数据靠 ExecuteJavaScriptAsync。这是最常用的单向通道// C# 执行页面里的 JS 代码 string js document.getElementById(status).innerText 来自C#的消息;; _browser.GetMainFrame().ExecuteJavaScriptAsync(js); // 低版本的 CefSharp 里也可以直接写在 browser 上 // _browser.ExecuteScriptAsync(js);逻辑说明GetMainFrame() 拿到主框架然后调用 ExecuteJavaScriptAsync 把脚本文本丢给 V8 引擎执行。这个方法名在不同版本里有差别新版本叫 ExecuteJavaScriptAsync老版本叫 ExecuteScriptAsync如果编译报找不到方法检查一下你手里的包版本换成对应的调用名即可。参数说明脚本执行是异步的不会阻塞 UI 线程但如果页面还没加载完脚本可能跑在错误的文档上下文里所以一般配合 3.2 里的 LoadingStateChanged 使用等 !e.IsLoading 再注入。另外脚本里如果引用了页面尚未定义的函数不会抛给 C#错误只出现在页面控制台排查时要用远程调试端口看后面第五章会讲。3.4 JavaScript 反过来调用 C#注册桥接对象单向下发脚本只解决了一半问题更多时候是页面里的按钮点了要触发 C# 去做文件读写、调本机接口。CefSharp 的做法是把一个 .NET 对象注册成 JS 的全局变量页面里直接当函数调。示例里的桥接对象是这样的// JsBoundObject.cs using System.Windows.Forms; public class JsBoundObject { // 这个方法会被页面 JS 直接调用弹一个本机消息框 public void ShowMessage(string text) { MessageBox.Show(页面调用 C# 成功 text); } // 带返回值的同步方法JS 那边能拿到结果 public int Add(int a, int b) { return a b; } }注册动作放在主窗体构造里注意时机// MainForm 构造里创建浏览器后立即注册 _browser.RegisterJsObject(bridge, new JsBoundObject()); // 然后再加载页面确保页面脚本执行时 bridge 已经存在 _browser.Load(https://example.com/page);页面的 HTML 里这样用button onclickbridge.ShowMessage(你好)调用 C# 方法/button p12 span idresult/span/p script // 同步拿到 C# 返回的整数 var sum bridge.Add(1, 2); document.getElementById(result).innerText sum; /script逻辑说明RegisterJsObject 把 JsBoundObject 实例映射成 JS 全局对象 bridge页面里直接 bridge.Add(1, 2) 就同步调用了 C# 方法返回值通过序列化传回 JS。这个机制底层是反射加 JSON 序列化所以方法参数只支持基础类型、字符串和简单对象别指望传 DataTable 或者自定义复杂类型。参数说明注册时机是这条链路里最容易翻车的地方。必须在页面脚本执行之前注册创建浏览器后立即调然后再 Load 地址如果浏览器已经加载完页面再注册bridge 在页面里就是 undefined需要重新 Load 一次才生效。另外 JS 是大小写敏感的C# 方法名暴露过去保持原名页面上写错了字母大小写调用会静默失败。老版本里 RegisterJsObject 是同步注册新版推荐 RegisterAsyncJsObject 走异步但 .NET 4.0 的老示例用同步注册完全没问题别为了追新把整个依赖版本抬上去。4. 排查与避坑白屏、闪退与初始化失败的五个现场4.1 白屏控件出来了页面一片空白现象窗体上能看到一块空白区域边框和背景色都正常地址栏有值但页面就是不渲染也没有任何报错。原因八成是输出目录少了资源文件。CEF 初始化时会按固定路径找 locales 目录和 .pak 文件找不到时不报错只是静默跳过渲染所需的资源加载。另外 CachePath 指向一个没有写权限的目录比如 Program Files 下也会造成白屏。解决先对照 2.2 节的文件清单把 bin 目录和 packages 原始资源做一次比对补齐 locales 和两个 .pak 文件然后在 CefSettings 里打开日志LogFile 指定路径LogSeverity 设为 Verbose跑一次去日志里搜 “Failed to load” 关键字。缓存目录就把 CachePath 换到 %LOCALAPPDATA% 下的应用专属目录。4.2 启动即崩BadImageFormatException 或 libcef.dll 加载失败现象程序一启动就弹 BadImageFormatException或者报 “Failed to load libcef.dll”有时候还会带一句 “An attempt was made to load a program with an incorrect format”。原因平台目标不匹配。libcef.dll 是 x86 版本但项目用的是 AnyCPU 或 x64CLR 加载本地 DLL 时按位数去找找不到就抛出这个异常。这是 CefSharp 最经典的启动崩溃没有之一。解决项目属性 → 生成 → 平台目标改为 x86同时检查“配置管理器”里的活动解决方案平台也是 x86。两个地方缺一不可光改项目属性不改解决方案平台编译产物还是错的。从那以后我每次新开 CefSharp 工程第一件事就是锁 x86省得后面排查一堆莫名其妙的加载错误。4.3 页面里 bridge 调不到JS 报 “bridge is not defined”现象页面控制台报 ReferenceError: bridge is not defined或者方法调用没反应。原因注册时机太晚。RegisterJsObject 在页面脚本执行之后才调用页面里拿到的全局对象根本不存在另一种情况是浏览器控件在注册之前已经通过构造函数加载了地址页面早就跑完脚本了。解决把注册动作挪到浏览器创建之后、Load 之前保证先注册后加载。如果窗体里还要初始化别的控件注意不要让任何代码在此之前触发 Load。已经注册不上的话最简单的是重新调一次 _browser.Load(...) 刷新页面注册就会生效。4.4 关闭窗体后进程不退出任务管理器里残留 BrowserSubProcess现象主窗体关掉了程序看起来退出了但任务管理器里还躺着好几个 CefSharp.BrowserSubProcess 进程杀都杀不干净。原因Cef.Shutdown 没有被调用。CEF 是多进程架构浏览器渲染跑在独立的子进程里托管的窗体关闭只是主进程退出的信号子进程需要 Cef.Shutdown 通知才能收尾。解决把 Cef.Shutdown 放在 Program.Main 里紧跟 Application.Run 之后别写在 FormClosing 事件里。关闭主窗体时可以先 _browser.Dispose() 释放浏览器资源再让 Application.Run 返回最后统一 Shutdown。顺序是Dispose 浏览器 → Run 返回 → Shutdown这个顺序别颠倒。4.5 VS2010 编译报错找不到 CefSharp 命名空间现象编译报一堆 “未能找到类型或命名空间 CefSharp”但引用列表里明明加了 DLL。原因引用加的是 NuGet 缓存里的高版本 DLL它依赖 .NET 4.5 以上才有的 APIVS2010 默认按 .NET 4.0 编译程序集加载时直接失败表现为命名空间都找不到。另一个常见原因是目标框架是 .NET 4.0 Client Profile精简版框架缺程序集。解决用工程包内自带的 DLL 重新添加引用不要用 NuGet 里新下的版本目标框架确认是 .NET Framework 4不是 Client Profile。VS2010 新建工程的默认值就是 Client Profile很多人在这里栽过检查一次能省半天时间。5. 运行与配置本地页面加载、脚本注入与远程调试5.1 加载本地 HTMLfile:// 协议与路径处理实际项目里内嵌浏览器用得最多的是加载本地页面——产品说明书、报表模板、操作手册这些资源不需要联网打包进程序目录最省事。示例里加载本地页面的写法是string path Path.Combine(Application.StartupPath, wwwroot, index.html); _browser.Load(file:/// path.Replace(\\, /));逻辑说明file:// 协议是本地文件的标准访问方式Windows 路径里的反斜杠要替换成斜杠否则 CEF 解析路径会出错。Path.Combine 拼出来的路径带反斜杠Replace 一下就行。如果页面里有引用的 css、js、图片它们也要一并拷到 wwwroot 下file:// 对相对路径的解析是按文件系统目录走的缺了就是页面样式全丢。参数说明如果你的本地页面需要接收参数比如打开某个详情页可以在 URL 后面拼 query形如 file:///.../page.html?id123页面里用 location.search 解析。这个技巧在不引入路由框架的前提下最省事。注意本地页面和 http 页面在 CEF 里的 Cookie、localStorage 是隔离的别指望两边数据互通。5.2 页面加载完成后再注入脚本等一个准确时机上一章提到注入脚本要等加载完成示例里的实现是这样private bool _scriptInjected false; private void OnLoadingStateChanged(object sender, LoadingStateChangedEventArgs e) { if (!e.IsLoading !_scriptInjected) { var frame _browser.GetMainFrame(); if (frame ! null) { // 页面标题加个“已注入”标记用来验证脚本确实执行了 string script document.title document.title - C#已接管;; frame.ExecuteJavaScriptAsync(script); _scriptInjected true; } } }逻辑说明LoadingStateChanged 在页面加载的各个阶段都会触发主框架、子框架、图片资源的变化都会进来用 !e.IsLoading 只能过滤出“某一次加载结束”的时刻不一定是整个页面完成。所以这里加了一个 _scriptInjected 标志位保证注入脚本只执行一次。如果你注入的脚本是幂等的不加标志位也没事但最好养成加标志位的习惯防止重复注入造成页面状态错乱。参数说明GetMainFrame() 返回主框架对象用它执行脚本可以避开 iframe 的干扰有些页面会弹窗打开新窗口那个窗口的主框架和当前页面不是同一个脚本不会自动带过去。框架对象判空也不能省页面销毁瞬间 frame 可能是 null直接调用会空引用。5.3 远程调试端口用 DevTools 协议看页面内部CefSharp 页面里的 JS 报错、网络请求失败C# 这边是感知不到的全闷在页面里。最有效的排查手段是打开远程调试端口var settings new CefSettings { RemoteDebuggingPort 9222, // 其他配置不变 }; Cef.Initialize(settings, true, null);运行程序后另开一个浏览器访问 http://localhost:9222就能看到当前程序里所有页面实例的调试入口点进去是完整的调试面板DOM、Console、Network、Sources 全都有。页面里 JS 报什么错、哪个请求返回 404一目了然比在 C# 里到处插 MessageBox 高效得多。注意这个端口只在开发调试时开交付给用户前一定关掉否则任何人访问本机 9222 端口都能看到你程序里打开的页面内容。我一般把这段配置用 #if DEBUG 包起来正式编译自然不带。5.4 拦截网络请求给特定 URL 返回本地内容有些场景要拦截页面里的特定请求比如把远程的某个接口替换成本地 mock 数据。CefSharp 提供了 IRequestHandler 体系示例里如果没实现你在二次开发时可以这样加public class MockRequestHandler : CefSharp.Handler.RequestHandler { protected override bool OnBeforeResourceLoad( IWebBrowser browserControl, IBrowser browser, IFrame frame, IRequest request, IRequestCallback callback) { // 命中 mock 地址就改写 URL指向本地文件 if (request.Url.Contains(api/mock)) { request.Url file:///C:/mock/data.json; callback.Continue(); return true; } return false; } }// 使用 _browser.RequestHandler new MockRequestHandler();逻辑说明RequestHandler 是 CEF 请求生命周期的观察者OnBeforeResourceLoad 在每次请求发出前被调用return true 表示请求已被处理配合 callback.Continue() 继续流程。把请求 URL 改写成本地文件就能实现无后端的纯前端联调这在老项目升级时非常实用。注意 OnBeforeResourceLoad 是回调里执行的需要处理跨线程问题时用 browserControl.Invoke 包装。6. 二次开发改造把示例工程改成能上岗的生产级浏览器壳6.1 从单页面到多标签TabControl 与资源释放示例工程只有一个浏览器实例实际业务里往往要开多个页面。把 ChromiumWebBrowser 塞进 TabControl每个 TabPage 对应一个浏览器实例是最常见的改造方向。改造时注意维护一个映射表private DictionaryTabPage, ChromiumWebBrowser _tabBrowsers new DictionaryTabPage, ChromiumWebBrowser(); private void AddNewTab(string url) { var tabPage new TabPage(url); var browser new ChromiumWebBrowser(url); browser.Dock DockStyle.Fill; tabPage.Controls.Add(browser); tabControl1.TabPages.Add(tabPage); _tabBrowsers[tabPage] browser; }关闭标签时先 Dispose 浏览器再移除 TabPage别省这一步。多个浏览器实例共用同一个 Cef 进程Cef.Initialize 依然只调一次别在 TabControl 的每个页面里重复初始化。刚改造完建议开十来个标签页跑半小时观察任务管理器里子进程数量和内存占用确认释放逻辑没漏。6.2 桥接对象的最小化暴露给 JS 的 API 越窄越安全页面上能调 C# 方法是一把双刃剑。一旦 bridge 对象暴露了文件读写、进程操作之类的能力页面被注入恶意脚本时后果很严重。我的习惯是给桥接对象单独建一个类只放业务需要的方法参数做白名单校验返回值只给基础类型。比如上传文件的方法参数里只接文件路径字符串并且强制校验路径前缀不匹配直接拒绝。另外开发期开了远程调试端口上线前一定要关如果加载的是外部不受信页面建议把浏览器默认的右键菜单快捷键能力收一收避免用户从页面里触发敏感操作。CefSharp 的能力边界很宽但业务上应该刻意把它收窄。6.3 改造后的验证清单每次改完都强制走一遍我从自己翻车的经历里总结了一套验证顺序改造完按这个跑第一步确认 x86 平台目标和 .NET 4 框架没被动过第二步跑一遍原始示例确认环境基线是好的第三步加载自己的页面分别验证 http 和 file:// 两种地址第四步页面按钮触发 C# 方法、C# 注入脚本改页面文本两条链路各测一次第五步连续开关标签页观察内存回不回落第六步正常退出确认任务管理器没有 BrowserSubProcess 残留。这套流程十分钟跑完能挡住九成以上的低级回归。从那以后我每次接手 CefSharp 相关需求都强制先跑一遍原示例再动代码很多“诡异问题”其实是跳过基线的结果比如机器上 DLL 版本不对、平台目标被改成 AnyCPU、缓存目录没权限这些和你的业务代码毫无关系却会浪费你一下午。先把地基夯一遍再往上盖楼这习惯让我少踩了无数坑。希望帮到你。本文还有配套的精品资源点击获取
