简介：面向C#桌面开发者的VLC播放器集成示例包，基于Visual Studio 2010与VLC.DotNet，适合已具备WinForms基础、希望在自有应用中嵌入本地视频播放能力的中级开发者。内容聚焦VLC控件封装、libvlc运行库与plugins插件部署、媒体播放和暂停等事件响应，可帮助读者理解.NET环境下调用VLC的目录组织与依赖配置，规避常见的库路径错误和插件缺失问题。压缩包共42个文件、约2.16MB，以C#源码、DLL动态库、EXE可执行文件、resx资源及sln/csproj工程文件为主，另含配置、清单和调试产物，能够还原一个可编译的示例工程。已有482人学习，适合作为VLC播放器二次开发的基础样板和排错参照。

1. 接手老旧工控界面时，客户只提了一个需求：把外部播放器嵌进窗口

某开发者接过一个老上位机项目，客户要求把原来“点一下按钮就跳出外部播放器”的流程改成内嵌播放。第一反应是使用 WinForms 自带的 Windows Media Player 控件，结果客户发来一个 H.265 的 MP4，画面黑着，声音也没有。改用 WPF 的 MediaElement，也一样不行。折腾两天才想明白：解码这件事不该让 C# 来做。VLC 播放器开发在 C# 里真正要做的，是把 libvlc 这层原生内核接住，剩下的交给它。这份基于 VLC 的 C# 播放器工程就是按这个思路搭的：WinForms 或 WPF 只负责窗口、按钮、进度条，解码、渲染、音轨切换、字幕加载全在 libvlc 里跑。它适合手里有 VS2010 老工程、又不得不支持一堆奇怪封装格式的开发者，也适合想搞清楚“托管代码怎么驱动原生解码器”的人。

2. 技术选型与整体架构：C# 外壳加 libvlc 内核的两层分工

老工程的约束很硬：VS2010、.NET Framework 4.0、C# 4.0，连async/await和字符串插值都没有。这个前提决定了选型不能照抄现在网上那些示例代码，得先把“用哪条路把 libvlc 接进来”这件事定死，否则后面每写一行都在还债。

2.1 三条路摆在面前，老工程多半只能走第三条

在 Windows 桌面上做播放器，绕不开三种做法，各自的代价差别很大：

真正实施时，第一种方案的失败率最高：测试机装了完整解码包能播，客户机器上一个精简版系统就黑屏，而且没有任何错误提示。第二种方案在新工具链上是首选，LibVLCSharp 把事件、媒体列表、快照都封好了；但如果手上就是 VS2010，NuGet 包还原会直接报目标框架不兼容。所以这个工程选了第三条：直接对libvlc.dll写DllImport。代价是要自己管指针，好处是编译产物干净，扔到任何一台装了 VC 运行库的 Windows 上都能起。

提示：如果项目还有升级空间，先升到 .NET Framework 4.6.1 以上再上 LibVLCSharp，能省掉后面一大半的封送调试工作。只有在工具链彻底动不了的时候，才值得自己写 P/Invoke。

2.2 运行时结构：C# 只管窗口，libvlc 管解码

整个运行时是清晰的两层。上层是托管世界，包括窗体、按钮、进度条、播放列表数据；下层是 libvlc 的原生世界，包括 demux、解码器、音频输出、视频输出模块。两层之间只有三样东西在流动：一个IntPtr实例句柄、一个IntPtr窗口句柄、一串事件回调。

具体链路是这样的：C# 先调libvlc_new拿到实例句柄，这个实例内部会去加载plugins目录下的几百个模块；然后用libvlc_media_new_path把文件路径变成一个媒体对象；再libvlc_media_player_new_from_media生成播放器，并把 Panel 的 HWND 通过libvlc_media_player_set_hwnd交给它；最后libvlc_media_player_play触发一个独立线程去解封装、解码、往那个 HWND 上贴画面。

理解这一点很关键：视频画面并不在 C# 的绘图循环里。libvlc 在 Windows 上默认使用 Direct3D 输出模块，它直接在那个 HWND 上创建自己的交换链。这意味着你在 Panel 上画的任何东西都会被盖住，WPF 里的Grid也永远压不住视频——这种现象叫 airspace 问题，属于架构层面的限制，调 ZIndex 没用，要盖 UI 只能用无窗口渲染（第 6 章会讲）。

音频走的是另一条完全独立的路径，由--aout指定的输出模块处理，和窗口句柄无关。所以会出现“有声音没画面”这种典型故障：音频输出初始化成功，视频输出因为硬件加速失败而放弃，两者互不影响。

2.3 目录结构与各文件职责

工程按“界面 / 封装 / 冒烟测试”切成三块，好处是封装层可以脱离界面单独测：

VlcPlayerDemo/ ├─ VlcPlayerDemo.sln ├─ src/ │ ├─ VlcPlayerDemo.UI/ WinForms 界面工程 │ │ ├─ MainForm.cs 按钮、进度条、音量条的事件处理 │ │ ├─ MainForm.Designer.cs │ │ └─ VideoSurfacePanel.cs 承载视频的 Panel，只负责交出 HWND │ ├─ VlcPlayerDemo.Core/ 封装层，不引用任何界面库 │ │ ├─ VlcNative.cs DllImport 声明，纯声明不写逻辑 │ │ ├─ VlcArgs.cs 启动参数拼装 │ │ ├─ VlcInstance.cs libvlc 实例，全局唯一 │ │ └─ VlcPlayer.cs 单文件播放器，状态机 + 事件 + 释放 │ └─ VlcPlayerDemo.Cli/ 控制台冒烟测试，不开界面就能验证能否播放 └─ lib/ └─ libvlc/win-x86/ ├─ libvlc.dll ├─ libvlccore.dll └─ plugins/ 几百个 .dll，缺一个都可能播不动

VlcNative.cs刻意只放声明，一个业务方法都不写。这样升级 libvlc 版本时，只需要对照libvlc.h核对这个文件，改动边界非常清楚。VlcInstance和VlcPlayer分离，是因为实例的创建成本很高（要扫描并加载 plugins 目录），而播放器是每次换片都要新建的；如果混成一个类，切歌就得反复libvlc_new，表现为每次换片卡顿一两秒。

VlcPlayerDemo.Cli这个控制台项目看起来多余，实际是排障时最有用的东西：界面出问题时，先在控制台里Play一个文件，如果控制台能出声出画，说明问题在 UI 层；如果控制台也不行，那就是原生库或参数的问题，两者能直接分清。这条经验后面第 5 章还会用到。

3. 跑起来：从零到能播放一个本地文件

这一章是从零到有画面的最短路径。整个过程里，真正花时间的通常不是写代码，而是把原生运行库摆到正确的位置，以及确认窗口句柄交对了。

3.1 准备原生运行库，plugins 目录是命脉

libvlc.dll只是外壳，真正的解码能力全在plugins目录下的几百个.dll里，包括libavcodec_plugin.dll、libd3d11_plugin.dll、libdirectsound_plugin.dll等等。常见的错误是只拷了libvlc.dll和libvlccore.dll两个文件，程序能启动、libvlc_new也返回非零，但一播放就静默失败——因为没有任何解封装和输出模块可用。

正确的做法是从 VLC 的发行包里取三个东西：libvlc.dll、libvlccore.dll、plugins目录，位数必须和你的进程一致。32 位进程用win-x86，64 位进程用win-x64，混用会得到BadImageFormatException或者更隐蔽的加载失败。

VS2010 用的是老式 csproj，没有 SDK 风格的CopyToOutputDirectory批量拷贝，最省事的是加一个后期生成事件，把 plugins 整个目录 xcopy 到输出目录：

<PropertyGroup> <!-- 每次生成后把 plugins 同步到 bin 目录，注意末尾反斜杠，否则 xcopy 会问是文件还是目录 --> <PostBuildEvent>xcopy /E /I /Y "$(SolutionDir)lib\libvlc\win-x86\plugins" "$(TargetDir)plugins\"</PostBuildEvent> </PropertyGroup>

/E表示包含空子目录，/I表示目标不存在时按目录处理，/Y表示不弹覆盖确认。这条命令放在生成事件里而不是手工拷贝，是因为 plugins 目录有上千个文件，手工同步迟早会漏，漏掉的那个恰好就是某个格式缺的解码器，排查起来很容易出错。

运行时还需要告诉 libvlc 去哪里找 plugins。默认它会去 exe 同级目录下找plugins，所以只要目录结构对，不用额外设置环境变量。如果想放到别处，就得在启动参数里加--plugin-path=...，并且这个参数要写在libvlc_new的 argv 里。

3.2 最小闭环：初始化、建媒体、绑窗口、播放

先看启动参数怎么拼。libvlc_new接受的是char**，第一个元素约定是程序名，libvlc 会跳过它，真正的开关从第二个开始：

// VlcArgs.cs —— 只负责把 C# 字符串数组变成 libvlc_new 能吃的 argv internal static class VlcArgs { public static IntPtr Create(string[] args, out IntPtr[] stringPtrs) { stringPtrs = new IntPtr[args.Length]; var box = new IntPtr[args.Length]; for (int i = 0; i < args.Length; i++) stringPtrs[i] = Marshal.StringToHGlobalAnsi(args[i]); // 参数是 ASCII 开关，用 Ansi 就够；路径走 media_new_path，那边才需要 UTF8 for (int i = 0; i < args.Length; i++) box[i] = stringPtrs[i]; var handle = GCHandle.Alloc(box, GCHandleType.Pinned); return handle.AddrOfPinnedObject(); } public static void Free(IntPtr arrayPtr, IntPtr[] stringPtrs) { if (arrayPtr != IntPtr.Zero) GCHandle.FromIntPtr(arrayPtr).Free(); foreach (var p in stringPtrs) if (p != IntPtr.Zero) Marshal.FreeHGlobal(p); } }

这段代码的关键在GCHandle.Alloc(box, GCHandleType.Pinned)：传给原生函数的指针数组必须固定在堆上，否则 GC 一整理内存，libvlc 拿到的就是一串野指针，表现为随机崩溃或参数神秘失效。libvlc_new内部会把参数各拷一份，所以调用返回后就可以释放这些字符串，不用把生命周期拖到播放结束。

接下来是播放器主体：

// VlcPlayer.cs —— 单文件播放器，生命周期从 Play 到 Dispose public sealed class VlcPlayer : IDisposable { private IntPtr _instance; private IntPtr _player; private VlcEventCallback _callback; // 必须存字段，见 4.1 public VlcPlayer() { string[] argv = new string[] { "vlc", // argv[0] 是程序名，libvlc 会跳过 "--no-video-title-show", // 不显示文件名浮层 "--quiet", // 不往 stderr 打日志 "--avcodec-hw=any" // 优先硬件解码，失败自动回软解 }; IntPtr[] strPtrs; IntPtr argvPtr = VlcArgs.Create(argv, out strPtrs); try { _instance = VlcNative.libvlc_new(argv.Length, argvPtr); } finally { VlcArgs.Free(argvPtr, strPtrs); } if (_instance == IntPtr.Zero) throw new InvalidOperationException("libvlc 初始化失败，先查 libvlc.dll 与 plugins 目录。"); } public void Play(string path, IntPtr hwnd) { ReleasePlayer(); IntPtr media = VlcNative.libvlc_media_new_path(_instance, path); if (media == IntPtr.Zero) throw new ArgumentException("路径无效或格式无法识别：" + path); try { _player = VlcNative.libvlc_media_player_new_from_media(media); if (hwnd != IntPtr.Zero) VlcNative.libvlc_media_player_set_hwnd(_player, hwnd); AttachEvents(_player); int rc = VlcNative.libvlc_media_player_play(_player); if (rc != 0) throw new InvalidOperationException("play 返回错误码 " + rc); } finally { // 播放器已持有自己的引用，这里可以立刻释放媒体对象 VlcNative.libvlc_media_release(media); } } }

几个参数值得说清楚。--avcodec-hw=any让 libvlc 优先尝试 D3D11VA 或 DXVA2 硬解，失败后自动退回软解，在低配机器上很有用；但在某些老显卡驱动上，硬解反而会花屏，这时改成--avcodec-hw=none就是立刻见效的开关。--no-video-title-show去掉画面上那行文件名浮层，做产品化的界面时基本都会关掉。

libvlc_media_release(media)放在finally里是必须的：libvlc_media_player_new_from_media会自己给媒体对象加一次引用，所以外层这份引用用完了就该还回去。新手最常见的写法是压根不释放，结果一个长跑程序切了几百次片之后，内存一路涨——每份没释放的 media 都握着已解析的元数据和索引。

3.3 把画面塞进 WinForms Panel 还是 WPF

WinForms 这条路最短，因为Control.Handle天然就是一个 HWND：

private VlcPlayer _vlc; private void MainForm_Load(object sender, EventArgs e) { _vlc = new VlcPlayer(); // 访问 Handle 会强制创建窗口句柄；不强制的话首次可能拿到 IntPtr.Zero var hwnd = videoPanel.Handle; _vlc.Play(@"D:\media\demo.mp4", hwnd); } private void MainForm_FormClosing(object sender, FormClosingEventArgs e) { if (_vlc != null) { _vlc.Dispose(); _vlc = null; } }

videoPanel.Handle这一行有个隐藏前提：控件必须已经创建。在Load事件里访问是安全的，因为在构造函数里访问会触发提前创建句柄，某些布局逻辑会因此算错尺寸。如果拿到的确实是IntPtr.Zero，libvlc 会另开一个自己的顶层窗口播放，用户看到的就是“视频跑到主窗体外面去了”，这个现象在第 5 章展开。

WPF 那边，最省事的是WindowsFormsHost里嵌一个Panel，把Panel.Handle传下去。直接用HwndSource的Handle也能播，但 WPF 的布局、变换、透明效果全部对视频无效——因为那是另一套渲染体系在往同一个 HWND 上画。如果产品要求视频上能叠半透明控件、能跟着动画缩放，就必须走无窗口渲染，用libvlc_video_set_callbacks把每帧像素拉回 C#，再自己贴到WriteableBitmap上。代价是 CPU 占用明显上升，1080p 每秒 25 帧的拷贝量不小，这个取舍在项目开始时就该定下来。

4. 核心模块拆解：事件回调、状态机与进度条

能播放只是起点。真正让界面“活”起来的是 libvlc 的事件回调，而这里恰好是最容易出问题的地方——回调来自原生线程，参数是裸指针，委托还可能被 GC 收走。

4.1 事件回调：把 C 的函数指针接成 C# 事件

libvlc 的事件模型是：先从播放器拿到一个事件管理器，然后把回调函数指针挂到特定的事件类型上。事件类型是整数常量，定义在libvlc.h里，常用的几个如下：

这些数值不要凭记忆抄，直接翻对应版本的libvlc.h核对，跨大版本时有调整。挂载的代码如下：

// 回调签名：void (*)(const libvlc_event_t*, void*) [UnmanagedFunctionPointer(CallingConvention.Cdecl)] internal delegate void VlcEventCallback(IntPtr evt, IntPtr userData); private VlcEventCallback _callback; // 关键：必须用字段持有引用 private void AttachEvents(IntPtr player) { IntPtr em = VlcNative.libvlc_media_player_event_manager(player); if (em == IntPtr.Zero) return; _callback = OnVlcEvent; int[] types = new int[] { 260, 261, 262, 265, 266, 267, 275 }; foreach (int t in types) VlcNative.libvlc_event_attach(em, t, _callback, IntPtr.Zero); } private void OnVlcEvent(IntPtr evt, IntPtr userData) { // 事件结构体里第一个 int 是 type，只读它就够，别去猜 union 的偏移 int type = Marshal.ReadInt32(evt); switch (type) { case 260: RaiseOnUiThread(() => OnPlaying()); break; case 261: RaiseOnUiThread(() => OnPaused()); break; case 265: RaiseOnUiThread(() => OnEndReached()); break; case 266: RaiseOnUiThread(() => OnError("解码失败")); break; case 267: // 时间值不从这个结构体里取，回头调 getter 重新读一遍更稳 long t = VlcNative.libvlc_media_player_get_time(_player); RaiseOnUiThread(() => OnTimeChanged(t)); break; } }

_callback = OnVlcEvent这一行是整段代码里最容易漏、后果最严重的一行。如果写成libvlc_event_attach(em, t, OnVlcEvent, IntPtr.Zero)，C# 会临时创建一个委托对象，方法返回后它就没有强引用了，GC 一跑就回收。而原生那边的函数指针还指着那块已经被回收的内存，下一次事件触发时就是CallbackOnCollectedDelegate异常或者直接进程崩溃，崩溃现场还完全不在你的代码里，查起来比较困难。

OnVlcEvent里只读type而不去解析完整结构体，是刻意的取舍。真实的事件结构体带一个 union，不同事件里 union 的布局不一样，时间值在 64 位下的偏移还得考虑对齐。与其花时间算偏移，不如拿到事件后回头调libvlc_media_player_get_time重新读一次——多一次跨边界调用，换来的是不会再因为结构体布局变化而失效。

RaiseOnUiThread负责把回调切回 UI 线程：

private void RaiseOnUiThread(Action action) { var form = _syncTarget; // 启动时传入的 Control 引用 if (form == null || form.IsDisposed) return; if (form.InvokeRequired) form.BeginInvoke(action); // BeginInvoke，别用 Invoke else action(); }

用BeginInvoke而不是Invoke是血泪经验。Invoke是同步等待，如果 UI 线程此刻正卡在某个长时间操作里（比如解析一批文件），原生线程就会被阻塞在回调上，而 libvlc 的事件分发是单线程的，一堵就是整个播放器失去响应。BeginInvoke只是投递，投完就返回。

4.2 播放状态机：界面只在五个状态之间跳

播放器界面本质上是个状态机，按钮的可用性、进度条能不能拖、加载动画要不要转，全看当前状态。工程里定义的状态不多：

public enum PlayerState { Idle, // 什么都没加载 Opening, // 调了 Play，还没出画面 Playing, Paused, Stopped // 手动停止或播完 }

状态迁移的规则要写死在一处，不能散落在各个按钮的点击事件里。比如EndReached之后必须回到Idle而不是Stopped，否则用户再点播放时，代码会以为还有媒体在播而跳过重新建媒体的步骤，表现为“播完一遍之后再点播放没反应”。这个 bug 我见过不止一次。

进度条有个细节值得单独说：不要用TimeChanged里的时间除以总时长来算百分比，直接用libvlc_media_player_get_position返回的 0 到 1 的浮点数。原因有两个，一是时间值是毫秒整数，短片的进度条会一跳一跳的；二是某些格式的总时长在播放初期是 0 或者不准，除出来是NaN或者离谱的数值，进度条直接飞出去。position 是内部按帧算的，稳得多。

拖动进度条时的时序也要注意：MouseDown时先记一个_isDragging = true，期间忽略所有TimeChanged回调对进度条的更新，MouseUp时才调libvlc_media_player_set_position。不这么做的话，手还没松开，进度条就被回调拽回去了，用户体验像是拖不动。

4.3 进度、音量、快进的参数换算

libvlc 的几个数值接口单位不统一，混用会导致“音量调不动”或者“进度条按百分比传了毫秒”这类问题：

音量这块有个实用技巧：不要自己维护一个音量变量然后直接设，先调libvlc_audio_get_volume读回当前值，再在它基础上加减。因为部分音频输出模块会钳制返回值，你设 150 它可能实际是 100，界面上滑块的位置和真实音量就会脱节。读回来再画滑块，界面和实际永远一致。

倍速播放要注意音频变调问题。libvlc 默认会做时间伸缩，但老版本的--audio-time-stretch在部分输出模块上不生效，2 倍速时声音会变尖。做网课类应用的话，这个开关得在启动参数里显式打开。

5. 避坑与排查：五个真实翻车现场

下面这几条，基本都是我在调试过程中真实遇到过并且卡了不止半天的。每条按“看到什么现象、根因在哪、怎么改”写，照着对号入座能省不少时间。

5.1 崩溃与退出类问题

现象一：程序启动就崩，异常信息是CallbackOnCollectedDelegate，堆栈指向一个完全陌生的地址。

原因是事件回调的委托没有强引用，被 GC 回收后原生侧还在调。解决方式是给VlcPlayer加一个private VlcEventCallback _callback;字段持有它，并且在Dispose之前不要置空。如果挂了多个播放器实例，就把委托存进一个静态的List<Delegate>，用完再移除，别指望局部变量。

现象二：点关闭按钮时偶发崩溃，异常在libvlc_media_player_release里面。

释放顺序错了。正确顺序是：先libvlc_media_player_stop，再libvlc_media_player_release，最后libvlc_release（实例）。如果先释放实例，播放器内部还持有指向实例的指针，release 的时候就会访问已经释放的内存。另外，stop是异步的，某些版本里紧接着 release 仍然不安全，稳妥做法是先 detach 所有事件，再 stop，再 release，中间不做任何等待。

5.2 画面与音频类问题

现象三：有声音没画面，或者画面在窗体外面单独弹了一个窗口。

两种情况。第一种是set_hwnd传了IntPtr.Zero，libvlc 就自己创建顶层窗口；检查点是在Load之后取panel.Handle，并且打印出来确认非零。第二种是硬件解码初始化失败，视频输出模块退回了一个独立窗口。改法是在启动参数里加--avcodec-hw=none先验证是不是硬解的问题，确认后在设置里给用户一个“关闭硬件加速”的开关——老显卡驱动上这个问题出现频率不低。

现象四：播放特定文件直接报错，控制台里一行日志都没有。

先看是不是路径问题。libvlc_media_new_path内部按 UTF-8 解析，而Marshal.StringToHGlobalAnsi在中文系统上按 GBK 编码，带中文或空格的路径就会变成乱码，文件当然打不开。签名上要显式标注[MarshalAs(UnmanagedType.LPUTF8Str)] string path。如果是网络流地址，则改用libvlc_media_new_location，两者不能混用。

现象五：切歌几次之后，播放器彻底没声音了，重启程序才恢复。

大概率是每次Play都新建了播放器却没释放旧的，音频输出设备被占满。解决方式是在Play开头先调ReleasePlayer()，把上一个播放器 stop 并 release。另外，libvlc_audio_set_volume在播放器重建后要重新设一次，音量是绑在播放器上而不是实例上的，很多人以为它是全局设置。

排查这类问题的通用手法是加启动参数--verbose=2，libvlc 会往 stderr 打详细日志。在 WinForms 里 stderr 看不见，最简单的做法是先用第 2 章提到的那个控制台冒烟测试项目跑一遍，日志直接打在窗口里，比在界面里猜快得多。

6. 二次开发：播放列表、截图与自定义渲染的改造思路

工程跑通之后，真正的工作才刚开始。按投入产出排序，最值得先做的是播放列表，因为它是所有播放器类产品的骨架。

libvlc 自己带了一套libvlc_media_list_player，可以把多个 media 塞进一个 list，然后交给 list player 顺序播放，还能设循环和随机模式。但我不建议直接用它的自动切歌——它的事件模型和你的 UI 状态机对不上，容易出现“列表里已经切到下一首，界面上还显示上一首”的错位。更稳的做法是自己维护一个List<string>加一个当前索引，在EndReached事件里做索引加一然后重新Play。这样切歌逻辑完全在你手里，暂停、跳过、删除当前项都好处理。

截图功能只需要一行调用：

// 宽高传 0 表示使用视频原始分辨率；路径必须是 libvlc 能写的绝对路径 int rc = VlcNative.libvlc_video_take_snapshot(_player, 0, @"D:\shots\snap.png", 0, 0);

注意它必须在播放中调用才有效，暂停状态在部分版本里会截出黑图，稳妥做法是先记下当前 position，播放状态下截图再恢复。

真正拉开差距的是无窗口渲染。用libvlc_video_set_callbacks注册 lock、unlock、display 三个回调，libvlc 每解出一帧就调一次你的 display，像素数据通过IntPtr传进来。拿到之后可以贴到WriteableBitmap，也可以直接喂给图像算法做识别、测量、叠加标注。这条路上有两个要注意的：一是像素格式要显式用libvlc_video_set_format设成RV32（BGRA），否则拿到的可能是 YUV，转起来很麻烦；二是三个回调同样要用字段持有委托，和第 4 章那个坑一模一样。

验证改造是否成功的顺序，我一般是这么走的：先在控制台项目里验证新接口能返回预期值，再接到界面上验证交互，最后才做压力测试，比如连续切五百次片看内存曲线是否平稳。跳过第一步直接改界面的结果，就是出了问题分不清是自己代码写错了还是原生调用失败了。

说个教训。早些年我图快，改完VlcPlayer的重建逻辑直接编译运行，点了两下能播就交付了。结果客户那边连续切歌半小时后崩溃，日志里什么都没有。从那以后我每次碰句柄重建、事件挂载这类改动，都强制走一遍“控制台连播一百次 + 任务管理器看内存 + 手动切到片尾触发 EndReached”这组合动作，不管改动看起来多小。这套动作五分钟能跑完，比事后去客户现场捞崩溃日志便宜太多。希望帮到你。

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