企业官网建设流程全解析

简介：面向使用C#的桌面开发者，CEF125 x64-H264发布包可在.NET4.6.2、Win10/11中嵌入Chromium6422内核，补齐H.264播放，兼容CefSharp125系列，适合WPF等应用加载网页、播放视频或混合界面集成。包内共74个文件、约134.28MB，以9个dll运行库和58个多语言pak资源为主，辅以快照、配置、示例及日志；多语言资源覆盖常见地区，便于按目标市场保留语言包，目录围绕运行依赖组织，方便排查加载或对照部署。已有261人学习。价值在于免去自行编译支持H.264的CEF的繁琐流程，可直接用于x64项目替换内核、验证视频兼容，避免运行缺库与解码异常，并借助示例与日志定位初始化、资源路径和依赖问题，减少环境搭建中的试错成本。

1. WPF 内嵌浏览器放不了 H.264：这份 CefSharp 125 发布包到底补了哪块

去年接手一个 WPF 项目，页面里要播一路 mp4 监控回放，<video>标签写得好好的，Chrome 里能放，一到 CefSharp 里就黑屏转圈，canPlayType直接返回空字符串。查了两天才确认不是代码问题——CEF 的标准构建用的是 Chromium 的 ffmpeg 分支，H.264/AAC 这套专有编解码根本没编进去。这份发布包就是针对这个点的：cef 125、CefSharp 125，对应 Chromium 6422 分支，x64 架构，编译时打开了专有编解码，把 libcef 那一套二进制打成可整包替换的 DLL 发布包，附一份替换说明。适合已经在用 CefSharp 做 WPF 内嵌浏览器、需要在页面里播监控流、教学视频、工业相机预览的 C# 开发者，也适合那些不想从 depot_tools 拉几百 G 源码自己编一遍的人。

2. CEF 125 对位 Chromium 6422：版本绑定关系与 x64 专包的选型理由

2.1 三层版本号：CefSharp、CEF、Chromium 少一层都对不上

很多人以为 CefSharp 的版本号就是随手编的，其实它是一条强绑定的版本链。你引用的 CefSharp NuGet 包版本决定了它能接受哪个 CEF 二进制，而 CEF 的 milestone 又对应一个固定的 Chromium 分支号。标题里的三个数字刚好把这条链说全了：

表里最后两行是这份包真正的价值所在。CEF 每个 milestone 内部还会迭代小版本，但跨 milestone 是不兼容的——托管层调libcef.dll的导出函数，函数名和参数结构在 milestone 之间会变，所以 125 的 CefSharp 只能配 125 的 CEF 二进制，拿 124 的 DLL 顶上去，运气好是初始化失败，运气差是初始化成功、跑到第二个页面才随机崩，这种玄学问题最难查。

落地第一步不是急着替换文件，而是先把你手头项目期望的版本问出来。CefSharp 把版本信息透出来了，初始化之后打一行日志就能看到：

// 放在 Cef.Initialize 之后、浏览器创建之前 Console.WriteLine("CefSharp: " + Cef.CefSharpVersion); // 托管包版本 Console.WriteLine("CEF: " + Cef.CefVersion); // 二进制版本，含 git hash Console.WriteLine("Chromium: " + Cef.ChromiumVersion); // 形如 125.0.6422.xxx Console.WriteLine("Runtime: " + Cef.RuntimeVersion); // 框架与架构

Cef.CefVersion后面通常带一串+g1a2b3c4的 git 短哈希，这个哈希就是你比对发布包的依据。把新包的libcef.dll换进去，再跑一遍这段输出，版本号和哈希应该和包内说明里写的一致。如果换完之后CefVersion没变，说明文件根本没被加载——它还在读输出目录里那份旧的，这事儿我在第 5 章会单独说。

还有一点容易忽略：Cef.RuntimeVersion会告诉你当前进程实际跑在什么框架上。x64 的libcef.dll被 AnyCPU 进程以 32 位方式加载，是新手最常撞的墙。

2.2 官方构建为什么天生没有 H.264，以及自己编的代价

Chromium 的编解码分两套品牌：ffmpeg_branding="Chromium"和ffmpeg_branding="Chrome"。前者是开源发行版用的，只带 VP8/VP9/AV1/Opus/Theora 这些免专利的；后者才打开proprietary_codecs=true，把 H.264、AAC、MP3 编进去。CEF 官方发布的二进制默认走前者，所以你在 CefSharp 里放 mp4 一定失败，这不是配置问题，是二进制里压根没有那个解码器。

要自己补上，常规路径是拉 depot_tools、fetch chromium、再gclient runhooks加 GN 参数编译，磁盘占用百 G 起，第一次完整编一轮机器要跑几个小时，中间还可能因为网络、SDK 版本、Windows SDK 缺失各种中断。对绝大多数做业务系统的团队来说，这个投入产出比很差——你要的是能放视频，不是要维护一套 Chromium 构建链。

所以这类「已经带专有编解码的 x64 发布包」的定位很明确：省掉构建环节，直接替换二进制。代价是版本被锁死在这个包里，后续升级得跟着发布方走，不能自己在 CefSharp 里随手改成CefSharp.Wpf 126.x然后指望它还能用——托管包一升级，ABI 就变了，包里的二进制立刻作废。

选型上还有两个常见替代。一是 WebView2，基于 Edge，H.264 天生就有，缺点是你对内核版本、启动参数、缓存目录的控制权弱很多，而且目标机得装运行时；二是继续用标准 CEF，把视频转成 VP9/WebM 再播，转码成本和画质损失得自己扛。如果业务里 mp4 是硬需求、又需要 CEF 那套细粒度控制（自定义 scheme、请求拦截、离屏渲染），那这种带编解码的整包替换就是最省事的路子。

2.3 确认包的架构与依赖，再决定往哪儿放

拿到包别急着解压覆盖。先做两件事：确认目标进程是纯 x64，确认目标机有 VC++ 运行库。

第一件在项目文件里定死，不要靠 IDE 的平台下拉框，那个东西在别人机器上、在 CI 上经常被重置：

<PropertyGroup> <!-- 强制 x64，杜绝 AnyCPU 在 32 位宿主里加载 x64 的 libcef --> <Platforms>x64</Platforms> <PlatformTarget>x64</PlatformTarget> <Prefer32Bit>false</Prefer32Bit> <RuntimeIdentifier>win-x64</RuntimeIdentifier> </PropertyGroup>

Prefer32Bit这个开关要显式关掉。它对 exe 项目在 AnyCPU 下有效，不关的话，一个 AnyCPU 的 exe 在 64 位系统上仍然会以 32 位启动，然后去加载 x64 的libcef.dll，直接BadImageFormatException。这类错误信息里通常只写「试图加载格式不正确的程序」，不会告诉你是位数问题，第一次遇到能耗掉半天。

第二件是运行库。CEF 的二进制依赖 MSVC 运行时，目标机没装对应的 VC++ Redistributable，表现是双击没反应或者启动瞬间退出、事件日志里一条 SideBySide 错误。开发机一般装了 Visual Studio 所以看不出来，一上客户机就翻车。发布前用dumpbin /dependents libcef.dll看一眼依赖列表，把该带的运行时一起带上，比事后远程排查便宜得多。

3. 发布包落地：DLL 目录、csproj 复制规则与 Cef.Initialize 参数

3.1 解包后的目录结构与硬依赖清单

包解开之后是一组平铺的二进制加若干子目录。哪些是硬依赖、哪些缺了只是降级，心里要有数，不然出问题只能整个目录瞎替换：

locales目录可以裁剪，只留zh-CN.pak和en-US.pak能省几 MB，但别把整个目录删掉，CEF 启动时会去找对应语言的 pak，找不到虽然不崩，日志里会一直刷警告。至于编解码到底落在哪个文件上，不同构建方式不一样，有的会把 ffmpeg 静态链进libcef.dll，有的会额外带一个 ffmpeg 模块，以包内说明为准，不要凭网上老帖子的文件列表去删东西。

替换的原则只有一条：整组替换，不要混搭。新旧版本的icudtl.dat、snapshot_blob.bin和libcef.dll之间是有版本校验的，混着用可能出现「能启动但页面渲染成马赛克」这种诡异现象。

3.2 csproj：把包内文件按原目录结构复制到输出目录

手工往bin里拖文件是最容易出事的方式，因为Clean一次就没了，而且新同事拉代码之后完全不知道该放什么。正确做法是把包放进源码树，用项目文件控制复制：

<ItemGroup> <!-- cef\h264\x64 下是发布包的完整目录，RecursiveDir 保留子目录结构 --> <None Include="cef\h264\x64\**\*.*"> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> <Link>%(RecursiveDir)%(Filename)%(Extension)</Link> </None> </ItemGroup> <ItemGroup> <!-- 打包时同样带上，避免发布产物缺文件 --> <None Include="cef\h264\x64\**\*.*"> <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory> <Link>%(RecursiveDir)%(Filename)%(Extension)</Link> </None> </ItemGroup>

%(RecursiveDir)是关键，它保留了**通配时匹配到的相对子路径，locales\zh-CN.pak复制过去还是locales\zh-CN.pak，不会被拍平到根目录。PreserveNewest只在源文件更新时才复制，日常编译不会每次都搬几十兆，但代价是——你换了包但没改文件名，MSBuild 有可能认为目标文件更新而跳过。这一点第 5 章会展开。

Link元数据决定文件在输出目录里的相对路径，不写的话有时会被塞进带项目名的子目录，CEF 就找不到了。写完这段，dotnet build之后去bin\x64\Debug\net8.0-windows\下面看一眼，libcef.dll应该和 exe 平级。

3.3 Cef.Initialize 的顺序与几个必须显式设置的参数

CefSharp 的初始化只允许一次，且必须在任何ChromiumWebBrowser实例创建之前完成。WPF 里最稳的位置是App.OnStartup，放在base.OnStartup(e)之前：

protected override void OnStartup(StartupEventArgs e) { var baseDir = AppDomain.CurrentDomain.BaseDirectory; var settings = new CefSettings { // 子进程宿主路径，x64 下必须指向同目录的可执行文件 BrowserSubprocessPath = Path.Combine(baseDir, "CefSharp.BrowserSubprocess.exe"), // 界面语言，配合 locales 目录里的 zh-CN.pak Locale = "zh-CN", // 缓存目录务必放到可写的用户目录，不要留在 Program Files CachePath = Path.Combine( Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), "MyApp", "CefCache"), // 日志：排查媒体问题时唯一的黑匣子 LogSeverity = LogSeverity.Info, LogFile = Path.Combine(baseDir, "logs", "cef.log"), // 关掉 GPU compositing 只在确认显卡驱动有问题时才开 // WindowlessRenderingEnabled = false, }; // 媒体相关开关：允许自动播放，否则本地 mp4 要用户点一下才走 settings.CefCommandLineArgs.Add("autoplay-policy", "no-user-gesture-required"); // 需要页面调摄像头/麦克风时打开，用不到就别开 settings.CefCommandLineArgs.Add("enable-media-stream", "1"); // 进程退出时把子进程一起带走，避免残留进程锁文件 CefSharpSettings.ShutdownOnExit = true; CefSharpSettings.SubprocessExitIfParentProcessClosed = true; Cef.Initialize(settings, performDependencyCheck: true, browserProcessHandler: null); base.OnStartup(e); }

参数逐个说清楚。BrowserSubprocessPath不设的话 CefSharp 会按默认规则去找，一旦你的目录结构和 NuGet 默认布局不同就会失败，显式写死最省事。performDependencyCheck: true会在初始化阶段做一次依赖检查，缺 DLL 时直接抛出带文件名的异常，比后面莫名其妙的崩溃好定位得多——生产环境可以考虑关掉省几十毫秒，但开发期一定开着。

CachePath是个隐藏的坑点。默认情况下 CEF 会把缓存写到 exe 同目录，装在Program Files下就是只读的，表现是页面能开但登录态存不住、localStorage 每次重启都清空。显式指到LocalApplicationData下能一劳永逸。

LogFile和LogSeverity平时可以调成Disable，但排查媒体问题时必须开到Info。H.264 到底有没有被识别、解码器初始化成没成功、是不是回落到软解，这些信息只在日志里。

关掉浏览器的时候也要走一遍：

protected override void OnExit(ExitEventArgs e) { Cef.Shutdown(); // 必须调用，否则子进程可能残留并锁住 DLL base.OnExit(e); }

Cef.Shutdown()没调、或者调了但被异常跳过，下次启动时libcef.dll会被残留的子进程占用，编译时复制失败，报「文件被另一个进程使用」。这个报错指向的是编译环节，实际原因在运行时，很容易误判成项目配置问题。

4. H.264 能力验证：从 canPlayType 探测到 mp4 真机播放

4.1 先做能力探测，别等页面报错才回头查

换完包第一件事不是直接上业务页面，而是跑一次媒体能力探测。HTMLVideoElement.canPlayType返回三个值："probably"表示有解码器且有把握，"maybe"表示容器认得但编解码不确定，空字符串表示完全没戏。对 H.264 来说，标准 CEF 构建下返回的必然是空串，换成带专有编解码的包才会变成"probably"。

在 CefSharp 里用EvaluateScriptAsync把结果捞回 C# 侧：

private async Task ProbeMediaAsync(ChromiumWebBrowser browser) { // 三段探测：H.264 视频、AAC 音频、VP9 对照组 const string script = @" (function () { var v = document.createElement('video'); return JSON.stringify({ h264: v.canPlayType('video/mp4; codecs=""avc1.42E01E""'), h264_high: v.canPlayType('video/mp4; codecs=""avc1.640028""'), aac: v.canPlayType('audio/mp4; codecs=""mp4a.40.2""'), vp9: v.canPlayType('video/webm; codecs=""vp9""') }); })();"; var resp = await browser.EvaluateScriptAsync(script); if (resp.Success && resp.Result is string json) { // 期望结果：h264 / h264_high 为 probably，aac 为 probably，vp9 为 probably Debug.WriteLine("media probe => " + json); } else { Debug.WriteLine("probe failed: " + resp.Message); } }

avc1.42E01E是 Baseline Profile Level 3.0 的 codec string，avc1.640028是 High Profile Level 4.0，两个都测是因为有些构建只开了部分 profile。mp4a.40.2是 AAC-LC，单独测它是为了区分「视频有声音没有」这种情况——H.264 和 AAC 是两个独立的解码器，只补一半的构建确实存在。

EvaluateScriptAsync有个坑：它只能序列化基础类型，直接返回对象会变成 null，所以脚本里用JSON.stringify转成字符串，C# 侧再反序列化。另外这个调用必须在页面加载完成之后，BrowserInitializedChanged或FrameLoadEnd里触发，早了会拿到空结果。

4.2 MediaCapabilities：比 canPlayType 更贴近真实播放

canPlayType只回答「认不认识这个 codec string」，不回答「这个分辨率、这个码率能不能流畅解」。Chromium 提供了navigator.mediaCapabilities.decodingInfo，可以带上分辨率和帧率去问：

// 在页面控制台里执行，或者在 CefSharp 里 EvaluateScript 跑 const config = { type: 'file', video: { contentType: 'video/mp4; codecs="avc1.640028"', width: 1920, height: 1080, bitrate: 4000000, framerate: 30 } }; navigator.mediaCapabilities.decodingInfo(config).then(info => { console.log('supported:', info.supported); // 能不能解 console.log('smooth:', info.smooth); // 能不能流畅 console.log('powerEfficient:', info.powerEfficient); // 是否走硬解 });

powerEfficient: true基本可以判定走了 GPU 硬解。如果supported是 true 但powerEfficient是 false，说明在软解，1080p 勉强能跑，4K 就会掉帧。这个信息比canPlayType有用得多，因为它是 CEF 内部的媒体管线真实给出的判断，而不是简单的字符串匹配。

顺带说一句，CEF 里默认是可以直接访问chrome://gpu和chrome://media-internals的。想看硬解到底有没有生效、走的什么解码器，把浏览器导航到chrome://media-internals，播一次视频，里面会有一条完整的媒体事件记录，从 demuxer 到 decoder 初始化到首帧渲染，哪一步失败一目了然。这是排查媒体问题最有效的工具，比翻日志快。

4.3 真机播放验证：本地文件、网络流、断网重连三件套

能力探测通过不等于业务能跑。我一般会准备三个测试用例，按顺序过一遍：

// 用例 1：本地文件，排除网络因素 browser.LoadHtml(@" <html><body style='margin:0;background:#000'> <video src='file:///C:/media/test-1080p.mp4' autoplay muted controls width='100%'></video> </body></html>"); // 用例 2：HTTP 渐进式，验证网络栈和 range 请求 // browser.Load("http://127.0.0.1:8080/test-1080p.mp4"); // 用例 3：业务真实地址，通常是 HLS 或 DASH // browser.Load("https://your-domain/play/index.m3u8");

本地文件这一步最关键。如果本地 mp4 放不了，那一定是编解码问题，跟网络、跟服务器、跟跨域全都无关，排查范围立刻收窄。如果本地能放、HTTP 放不了，那就是网络栈或者 MIME 类型的问题，跟编解码无关。

muted属性要加上，不然自动播放策略会拦住，页面看起来像「卡在第一帧」。这就是为什么第 3 章里那条autoplay-policy参数要显式设置——不设的话每次都得让用户点一下播放按钮，用户会以为是 bug。

HLS（.m3u8）另说，CEF 原生不支持 HLS，得靠 hls.js 这类库在页面里做 MSE 播放。这时候MediaSource的支持度就成了关键，还是用同一套探测脚本加一项MediaSource.isTypeSupported('video/mp4; codecs="avc1.42E01E"')就能确认。

5. 避坑排查：加载失败、黑屏与 DLL 残留的五种现场

5.1 现象：启动瞬间退出，事件日志里一条 SideBySide 或找不到模块

原因：三种可能叠在一起——位数不匹配、缺 VC++ 运行库、缺chrome_elf.dll。位数问题最常见，尤其当解决方案里有多个项目，某个类库还留着 AnyCPU 的时候，宿主进程可能不是你以为的那个位数。

解决：先确认进程位数，任务管理器里看 exe 后面有没有(32 位)；再确认libcef.dll的位数，用dumpbin /headers libcef.dll | findstr machine，x64 应该输出8664。然后检查输出目录里chrome_elf.dll、icudtl.dat、snapshot_blob.bin是不是和libcef.dll平级。最后装一遍对应的 VC++ Redistributable。三步走完还没解决，就把performDependencyCheck开着跑一次，异常信息里会直接点名缺哪个文件。

5.2 现象：页面正常打开，mp4 黑屏转圈，或者只有声音没有画面

原因：只补了一半编解码，或者替换的libcef.dll根本不是带专有编解码的那份。还有一种情况是复制规则被 MSBuild 跳过了——你换了包里的 DLL，但文件名没变、时间戳比输出目录里的旧，PreserveNewest判定为不需要复制，跑起来的还是旧文件。

解决：先跑 4.1 那段探测脚本，h264为空串就是二进制不对，h264有值但aac为空就是只有视频没有音频。确认二进制不对之后，别信编译日志，直接看bin目录里libcef.dll的文件大小和修改时间，和包里的源文件比一遍。对不上就dotnet build --no-incremental或者手动删bin、obj重新编译。这类问题我吃过一次亏，改了半天代码，最后发现是文件压根没被复制过去。

5.3 现象：开发机一切正常，装到客户机上白屏或直接崩溃

原因：开发机装了完整 SDK 和运行库，客户机是干净系统。缺的通常是 VC++ 运行库、缺少d3dcompiler_47.dll，或者客户机显卡驱动太老导致 GPU 进程反复崩溃、页面一直白屏。

解决：发布产物里把 VC++ Redistributable 一起带上，或者干脆用静态链接运行时的构建。显卡问题先在启动参数里加--disable-gpu跑一次，如果关掉 GPU 就正常了，说明是图形栈问题，可以进一步加--disable-gpu-compositing或者用vk_swiftshader走软件渲染兜底——性能差但至少能显示。别一上来就关 GPU，那等于放弃了硬解，1080p 以上会明显掉帧。

5.4 现象：换包后行为不一致，同一个页面时而正常时而报错

原因：新旧 DLL 混搭。CEF 的libcef.dll和icudtl.dat、snapshot_blob.bin、resources.pak之间有版本校验，混用不一定立刻崩，但会出现内存布局错位、随机崩溃、渲染异常这类很难复现的问题。另一种可能是输出目录里有历史遗留文件，比如上一个版本多出来的ffmpeg相关模块。

解决：替换前先整个清空输出目录，不要覆盖式复制。CI 上更稳妥的做法是每次构建前跑一次清理，或者干脆把 CEF 二进制放在独立的cef\子目录，用BrowserSubprocessPath和相关设置指向它，和项目输出隔离。判断有没有混搭，把包里所有文件的哈希列出来，和输出目录逐个比对，一条命令的事：

# 生成包内文件的哈希清单 find ./cef/h264/x64 -type f -exec sha256sum {} \; | sort -k2 > pkg.sha256 # 和输出目录比对 find ./bin/x64/Release/net8.0-windows -maxdepth 1 -type f \ -exec sha256sum {} \; | sort -k2 > out.sha256 diff <(awk '{print $1, $2}' pkg.sha256) <(awk '{print $1, $2}' out.sha256)

有差异的行就是没被正确替换的文件。这个手段看着笨，但比对着几十个文件肉眼比对可靠得多。

5.5 现象：路径里有中文或空格，初始化就失败

原因：CEF 的子进程启动参数对路径里的特殊字符处理不如想象中稳，尤其是没加引号的时候。另外装在Program Files下，缓存目录不可写，表现是「页面能开但登录状态丢失」。

解决：别把应用装在带空格或中文的路径下，这是最省事的。实在避不开，BrowserSubprocessPath和CachePath都显式传完整路径，让 CefSharp 自己对参数做转义。缓存目录一律指到LocalApplicationData，不要留在安装目录。这条经验来自一次现场排查，客户的机器用户名是中文，缓存路径拼出来的字符串里带了非 ASCII 字符，日志里只写「cannot create cache directory」，没有任何更多信息，查了很久才想到是路径问题。

6. 进阶：换包后的版本校验与子进程日志回溯

换 CEF 二进制这件事，做一次是手工活，做十次就得有套路。我现在固定用一套「换包三验」，每次替换完按顺序过，五分钟内能确认这次替换是干净的。

第一验是版本指纹。除了第 2 章那行Cef.CefVersion，我还会在启动日志里打上libcef.dll的哈希和大小，两者一起记录，出现问题时能回溯到具体是哪一次构建引入的：

var dll = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "libcef.dll"); var fi = new FileInfo(dll); using var sha = System.Security.Cryptography.SHA256.Create(); using var fs = File.OpenRead(dll); var hash = Convert.ToHexString(sha.ComputeHash(fs))[..16]; // 输出示例：libcef 125.0.6422.x size=214,xxx,xxx sha256=9F3A... logger.Info($"libcef {Cef.CefVersion} size={fi.Length} sha256={hash}");

第二验是自检页。我给自己准备了一个本地 HTML，页面加载完自动跑一遍能力探测、发起一次本地 mp4 播放、把结果通过CefSharp.PostMessage回传给 C# 侧。启动应用时如果检测到命令行带--selftest，就直接加载这个页面，全部通过才继续走正常流程。这套东西在客户现场特别值钱——出了问题时让现场同事带参数启动一次，把日志发回来，比远程连过去猜快得多。

第三验是子进程。媒体播放跑在 GPU 进程和渲染进程里，主进程崩了往往能看到子进程的日志。CefSharp.BrowserSubprocess.exe启动时会继承一部分命令行参数，加上--enable-logging --v=1可以让它输出更详细的日志。想看嵌入页面里的控制台和网络请求，开一个远程调试端口最方便：

// 只在调试构建里打开，正式包务必去掉 #if DEBUG settings.CefCommandLineArgs.Add("remote-debugging-port", "9222"); settings.CefCommandLineArgs.Add("remote-allow-origins", "http://127.0.0.1:9222"); #endif

启动后在本机浏览器里打开http://127.0.0.1:9222，能看到内嵌浏览器的完整 DevTools，元素、网络、媒体面板全都在，和在 Chrome 里调试网页没有任何区别。H.264 播放失败时，媒体面板里会明确写「no supported source」还是「decoder initialization failed」，这两个结论指向完全不同的排查方向。

最后说一条习惯。从那以后我每次换 CEF 二进制，都会先跑一遍能力探测三段式、再播一个 1080p 本地 mp4、最后比对一次文件哈希，三步全绿才动业务代码。这习惯是被一次「代码改了三小时、根因是 DLL 没复制过去」逼出来的，代价太大，不敢再省。希望帮到你。

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