C#调用FFmpeg实战：视频帧提取与进程封装全解析

作为一个常年跟视频处理和上位机打交道的C#开发者我可以说视频帧提取是绕不开的硬需求。不管是给监控系统做抓拍、给生产线的视觉检测提供图片样本还是给视频网站生成预览图本质上都是同一件事从视频流里取出那一瞬间的画面。而这件事在C#生态里最稳的答案就是FFmpeg。FFmpeg在视频处理领域的地位不用我多吹几乎所有播放器、剪辑软件、流媒体服务的底层都有它的影子。但C#开发者面对FFmpeg时的困惑往往不在FFmpeg本身而在于怎么把一个命令行工具优雅地集成进自己的程序里怎么处理进程通信、参数转义、性能瓶颈这些工程问题。这篇就是我基于实际项目经验做的完整拆解从命令参数到C#代码封装从单帧提取到批量并发把坑和心得一起写出来。1. 为什么视频帧提取最后选了FFmpeg1.1 绕不开的选型对比我最初做帧提取的时候其实先试过其他思路。用OpenCV的VideoCapture也能读帧但问题在于OpenCV对视频文件的解码依赖FFmpeg后端而且封装格式兼容性一般。遇到某些特殊编码的监控视频比如海康的H.265、大华的私有封装OpenCV经常直接罢工要么读不出帧要么颜色通道错乱。Windows自带的Media Foundation也能做但转场封装、自定义解码器的能力很差遇到MP4之外的老格式基本没辙。FFmpeg的优势在于它自己就是一个完整的解码框架。它内置了几乎所有主流编码格式的解码器包括H.264、H.265、VP9、AV1还支持各种奇怪的封装容器。这意味着你不是在赌某一个库的兼容性而是站在了整个视频解码生态的肩膀上。对C#开发者来说用FFmpeg做帧提取还有个额外好处它输出的是标准图片文件不需要你额外处理像素缓冲区省掉了大量底层内存操作的风险。1.2 进程调用模式为什么比C#封装库靠谱接触FFmpeg之后你会发现C#生态里其实有封装库比如FFmpeg.AutoGen、Xabe.FFmpeg这些。FFmpeg.AutoGen是直接绑定FFmpeg原生API性能很好但用起来极其痛苦——你得手动管理AVFormatContext、AVCodecContext这些指针还得处理内存释放一个疏忽就是内存泄漏或者access violation项目周期紧的时候真的会把人逼疯。我实际项目中选的是进程调用模式就是用System.Diagnostics.Process启动ffmpeg.exe传命令行参数。很多人觉得这样太“原始”但恰恰是这种方式最稳定。FFmpeg命令行本身久经考验各种参数组合的坑网上都有记录出问题了好排查。进程边界也把原生代码崩溃隔离在外部不会直接把你的C#进程带崩。性能上也不用担心进程启动开销无非几十毫秒而解码一帧视频通常要几秒到几十秒这点开销完全可以忽略。2. 环境准备与项目集成细节2.1 FFmpeg的安装与版本选择之前查FFmpeg安装教程的朋友很多这里把关键点说透。FFmpeg官方不提供Windows编译版的exe需要从第三方构建站点下载。常用的有gyan.dev和BtbN的GitHub Release这两个都是社区公认的靠谱来源。下载的时候注意区分full build和essentials build推荐直接下full版里面包含了libx264、libx265这些常用的第三方编码器免得后面需要的时候再折腾。版本选择上我建议优先用最新的release版本比如FFmpeg 6.x或7.x不要用太老的版本。新版本对H.265、AV1这些新编码格式的支持更完善而且修复了很多解码器的安全漏洞。下载之后解压到一个固定目录比如D:\Tools\ffmpeg\bin把这个路径加到系统环境变量Path里。命令行里能直接敲ffmpeg -version就算配好了。C#项目里其实可以不依赖环境变量直接用进程的完整路径这样部署到别的机器上更可控。但我还是建议开发环境配好Path因为调试的时候直接敲命令行验证参数很方便不用每次都在代码里加日志输出。2.2 C#项目的目录结构与FFmpeg文件放置一个常见的坑是发布部署时忘记把FFmpeg一起带上。我建议在项目里建一个tools目录把ffmpeg.exe和它依赖的dll一起放进去在代码里动态获取这个目录private static string GetFFmpegPath() { string baseDir AppDomain.CurrentDomain.BaseDirectory; string path Path.Combine(baseDir, tools, ffmpeg.exe); // 如果不存在则尝试使用环境变量中的ffmpeg if (!File.Exists(path)) { return ffmpeg; } return path; }这个做法的好处是发布的时候直接把整个输出目录打包就能跑目标机器不需要单独装FFmpeg。很多工控机、服务器上是没有图形界面的也不可能让你随便装软件这种绿色部署方式在工业场景下特别实用。2.3 进程参数的安全传递与转义这是C#调FFmpeg最容易翻车的地方。用ProcessStartInfo.Arguments传参时路径里一旦有空格、中文、特殊字符就可能导致参数被错误分割。比如输入路径是C:\My Videos\test 01.mp4直接拼字符串传过去FFmpeg会把路径拆成两个参数。正确做法是用ArgumentList它会自动处理转义。如果你必须在旧版.NET Framework上工作那就要自己手动加引号并处理内部的引号转义非常麻烦。所以我强烈建议能用.NET Core/.NET 5就用新版用ArgumentList一劳永逸地解决参数转义。另外要注意FFmpeg参数中涉及时间、比率这类带有小数点或冒号的字符在部分系统环境下需要确保文化设置是InvariantCulture不然不同语言区域的小数点不一样会导致参数解析出错。我后面代码里统一用了CultureInfo.InvariantCulture这也是我在多语言环境的工控机上踩过坑之后总结出来的。3. FFmpeg帧提取命令的参数级拆解3.1 核心参数逐项解析帧提取的命令核心就一句话定位到某一时刻输出某一帧。但参数怎么组合不同写法的性能差距是数量级的。先看最简单的ffmpeg -i input.mp4 -ss 00:01:23 -frames:v 1 output.jpg这条命令能跑但不是最优解。问题在于-ss放在了-i后面FFmpeg会先解码从视频开头到目标位置的所有帧然后才提取目标帧。如果视频有2小时你要提取第1小时23分的画面它就要解码整整1个多小时的视频慢得让人怀疑人生。正确写法是把-ss放在-i前面ffmpeg -ss 00:01:23 -i input.mp4 -frames:v 1 output.jpg这样FFmpeg会用快速定位的方式从关键帧位置开始跳转大幅减少解码量。精确定度上是按关键帧对齐的可能在目标时间的几帧误差范围内对于大多数截图场景完全够用。如果要求绝对精确那就得-ss放-i后面或者结合-accurate_seek参数但代价是解码耗时。接下来拆解几个常用参数-ss定位起点时间。格式可以是秒数如83也可以是HH:MM:SS.mmm。放在-i前面和后面的行为不同这是性能关键点。-frames:v 1只输出1个视频帧。等价写法是-vframes 1但-frames:v是更规范的写法。-q:v输出图片的质量。范围是2到31数字越小质量越高。-q:v 2基本无损适用于需要后续做图像识别的场景。默认值对不同格式不同但建议显式指定。-f image2强制指定图片输出格式。虽然能根据扩展名推断但显式指定可以避免扩展名怪异的兼容问题。-vf scale1920:1080输出分辨率缩放。如果原视频是4K但只需要1080p的图加这个参数能显著减少图片文件的体积。-an忽略音频流。提取单帧的场合没有音频因为不指定就直接抛弃了但如果你在处理可能存在音视频交错问题的文件时想更干净可以显式加。3.2 高级帧选择策略select、fps、thumbnail除了按时间点提一帧实际业务中还经常需要提取缩略图序列、均匀取帧、场景切换帧。提取每秒一帧最直观的方式是-vf fps1ffmpeg -i input.mp4 -vf fps1 -q:v 4 thumb_%04d.jpg这会按每秒1帧的频率输出图片文件名自动编号。它的原理是在时间戳维度上做采样比用-r更贴近帧提取需求。如果要做视频预览动图fps5或fps10的连续帧序列可以直接用来生成gif。提取场景切换的关键帧可以用select过滤器ffmpeg -i input.mp4 -vf selectgt(scene,0.4),scale1280:720 -q:v 4 scene_%04d.jpgscene是FFmpeg内置的场景变化检测值0到1之间越大越严格。gt(scene,0.4)表示画面变化超过0.4的帧才保留。这个做视频自动抽帧、内容分析的前置处理特别方便。thumbnail过滤器则是另外一个思路它不用固定帧率而是自动挑选一个代表帧ffmpeg -i input.mp4 -vf thumbnail100 -q:v 4 poster.jpgthumbnail100表示每100帧里挑出最“有代表性”的一帧适合生成视频封面图。我用它做过视频网站后台上传时的自动封面匹配度比随便取个时间点要高得多。4. C#实战代码从基础封装到业务落地4.1 单帧提取的完整封装回到C#侧把上面讲的参数和优化经验落成代码。我实际项目里的核心封装大概长这样using System; using System.Diagnostics; using System.Globalization; using System.IO; using System.Threading.Tasks; public class FFmpegFrameExtractor { private readonly string _ffmpegPath; public FFmpegFrameExtractor(string ffmpegPath) { _ffmpegPath ffmpegPath; } public async Taskbool ExtractFrameAsync( string inputVideo, string outputImage, double seconds, int quality 2, string? scale null, CancellationToken cancellationToken default) { var startInfo new ProcessStartInfo { FileName _ffmpegPath, UseShellExecute false, CreateNoWindow true, RedirectStandardError true, RedirectStandardOutput true }; // -ss 放在 -i 前面走快速定位路径 startInfo.ArgumentList.Add(-y); startInfo.ArgumentList.Add(-ss); startInfo.ArgumentList.Add(seconds.ToString(0.###, CultureInfo.InvariantCulture)); startInfo.ArgumentList.Add(-i); startInfo.ArgumentList.Add(inputVideo); if (!string.IsNullOrEmpty(scale)) { startInfo.ArgumentList.Add(-vf); startInfo.ArgumentList.Add($scale{scale}); } startInfo.ArgumentList.Add(-frames:v); startInfo.ArgumentList.Add(1); startInfo.ArgumentList.Add(-q:v); startInfo.ArgumentList.Add(quality.ToString(CultureInfo.InvariantCulture)); startInfo.ArgumentList.Add(-f); startInfo.ArgumentList.Add(image2); startInfo.ArgumentList.Add(outputImage); using var process new Process { StartInfo startInfo }; // 异步读取stderr避免缓冲区满导致死锁 Taskstring stderrTask process.StandardError.ReadToEndAsync(); try { process.Start(); await process.WaitForExitAsync(cancellationToken); string stderr await stderrTask; if (process.ExitCode ! 0) { throw new InvalidOperationException($FFmpeg退出码非0: {process.ExitCode}\n输出: {stderr}); } return File.Exists(outputImage); } catch (OperationCanceledException) { try { process.Kill(true); } catch { } throw; } } }这里有几个细节值得展开说明。第一是异步读取stderr这一步不是锦上添花而是生死攸关。FFmpeg默认把大量日志写到stderr如果RedirectStandardError设为true但你不去读缓冲区满了进程就会阻塞住表现为程序看起来“卡死”了。很多人一开始图省事用同步的ReadToEnd()其实也行但必须先启动进程再读否则会先等待进程结束而进程又在等待缓冲区释放直接死锁。我上面的写法用的是ReadToEndAsync()配合WaitForExitAsync逻辑上更安全。第二是加了-y参数。这个参数表示输出文件存在时直接覆盖不加的话FFmpeg进入交互模式等待用户输入y或n。在无人值守的进程调用场景里它会在那里干等然后表现为程序挂住。这是新手最容易碰到的隐性bug之一。4.2 批量提取与异步任务编排单帧提取封装好了批量也就水到渠成。批量场景有两种典型需求一是从多个视频里各取若干关键帧二是从一个长视频里均匀提取多个帧。后者的命令可以是在-ss上做多次调用也可以利用-vf fps直接产出一批图片。我在C#里倾向于发多次单帧提取任务这样每次调用独立便于记录日志、重试失败项、控制并发数。示例代码如下public async TaskListExtractResult BatchExtractAsync( IEnumerable(string video, double seconds) tasks, string outputDir, int maxConcurrency 4) { using var semaphore new SemaphoreSlim(maxConcurrency); var results new ListExtractResult(); await Task.WhenAll(tasks.Select(async item { await semaphore.WaitAsync(); try { string fileName ${Path.GetFileNameWithoutExtension(item.video)}_{item.seconds:0.##}.jpg; string outputPath Path.Combine(outputDir, fileName); bool success await ExtractFrameAsync(item.video, outputPath, item.seconds); results.Add(new ExtractResult(item.video, item.seconds, success, outputPath)); } finally { semaphore.Release(); } })); return results; } public record ExtractResult(string VideoPath, double Seconds, bool Success, string OutputPath);并发量控制很关键。FFmpeg是CPU密集型的解码一帧视频通常会跑满一个核心甚至多个核心。如果你在8核机器上盲目开20个并发上下文切换开销和内存压力反而会让总吞吐量下降。根据我的实测物理核心数减2到4是比较合适的起点然后再根据实际视频分辨率和编码格式微调。H.265解码比H.264更吃CPU并发数就要相应调低。这里顺带说一下为什么要用Task.WhenAll而不是简单循环同步调用。FFmpeg进程执行是CPU耗时一次调用可能几百毫秒到几秒。同步循环会导致UI线程或请求线程一直阻塞。在WPF或者WinForms项目里这就是界面卡死的元凶也就是热词里那个“winfrom卡”提问背后的根源。把任务丢到线程池或者Task里配合异步等待UI才能保持流畅。4.3 超时控制与进程清理在工业生产环境中最怕的是FFmpeg进程异常挂起不退出也不报错。这种情况通常发生在输入视频文件损坏、网络文件句柄异常、某些解码器卡死的时候。没有超时控制的代码会无限期等下去导致任务队列越积越多最终系统资源被耗尽。给进程加超时控制是我强烈建议加上的一层保护public async Taskbool ExtractFrameWithTimeoutAsync( string inputVideo, string outputImage, double seconds, TimeSpan timeout) { using var cts new CancellationTokenSource(timeout); try { return await ExtractFrameAsync(inputVideo, outputImage, seconds, cancellationToken: cts.Token); } catch (OperationCanceledException) { // 清理可能残留的临时文件 if (File.Exists(outputImage)) { File.Delete(outputImage); } throw new TimeoutException($FFmpeg帧提取超时{timeout.TotalSeconds}秒: {inputVideo}); } }超时时间设置要根据视频规格预估。1080p的H.264视频快速定位模式提取一帧通常1到3秒内完成。4K的H.265视频可能需要5到10秒。我一般用视频时长和分辨率估算一个上限再乘1.5作为安全余量。比如预估2秒的给5秒超时避免机器负载高时出现假超时。超时之后的进程清理也需要注意。CancellationToken取消后WaitForExitAsync会抛异常但FFmpeg子进程可能还在跑。所以我在catch块里调用了process.Kill(true)参数true指定连同子进程树一起杀掉。FFmpeg极少派生子进程但加上这个参数放心也防止万一它起了兄弟进程变成孤儿进程继续占着资源。5. 常见问题与实战避坑记录5.1 高频问题速查表C#调FFmpeg的过程中我在社区里看过、自己也踩过的高频问题整理成表方便快速对照现象根本原因解决方案程序卡死无响应stderr输出缓冲区未读取使用异步读取或至少启动后立即开始读输出文件是0字节参数错误或输入文件损坏查看stderr日志验证命令能否在命令行手动执行图片颜色不对pixel format理解错误输出png用-pix_fmt rgbajpeg用默认即可Access violation崩溃库绑定方式的内存管理问题换成进程调用模式远离指针路径有空格导致失败字符串参数未转义用ArgumentList代替手动拼字符串进程不退、占用文件视频文件损坏或解码卡死加CancellationTokenSource超时并强制Kill进程树颜色问题多说一句如果你提取的是带透明通道的视频或者输入源是RGBA格式的录屏文件输出jpg时会自动转成不透明背景这是正常行为。但如果你把png输出格式和某些特殊pixel format组合在一起会出现半透明图层变黑的问题。解决办法一般是在-vf里显式指定formatrgba或formatyuv420p看你的下游需要什么。5.2 缓存策略与重复帧提取优化一个常见的业务场景是同一个视频要反复提取多个时间点的帧。如果每次都从头跑一遍FFmpeg进程前面已经解码过的内容就全部浪费了。FFmpeg本身没有断点续传的概念但C#侧可以做一层缓存。我的做法是用视频文件的哈希值加上修改时间作为缓存键把已经提取过的帧结果保存起来。下次请求同一个视频的同一个时间点直接命中缓存返回文件路径完全不用再调FFmpeg。这个优化在监控视频回放这种高频访问场景里收益巨大原本几秒的响应时间可以压缩到几十毫秒。private string GetCacheKey(string videoPath) { FileInfo fi new FileInfo(videoPath); string hash Convert.ToHexString( System.Security.Cryptography.MD5.HashData( System.Text.Encoding.UTF8.GetBytes(videoPath))); return ${hash}_{fi.Length}_{fi.LastWriteTimeUtc.Ticks}; }注意缓存键里一定要放文件大小和最后修改时间因为视频文件可能被覆盖替换。只存路径哈希的话原文件被替换后你还在用旧缓存就会拿到过期画面这在视觉检测这种对时效性要求高的场景里会出大问题。5.3 高分辨率视频的内存与临时文件管理提取4K甚至8K视频的帧时输出图片的像素数据量很大。一张4K的jpg图片大概有8MB到15MB如果批量提取几百张磁盘空间瞬间就吃紧了。FFmpeg处理时还会在内存里保留解码帧缓冲区多个进程并发时内存压力不容忽视。我建议的做法是在批量任务中限制并发数的同时限制输出图片的最大尺寸。如果下游只需要做缩略图预览scale-2:720就把输出控制在720p宽度自动高度按比例计算且保证偶数避免某些编码器对奇数高度报错。这样既减少磁盘占用也降低视觉模型处理的图片大小整体吞吐量反而更高。临时文件方面如果提取过程是中间步骤不是最终结果比如生成帧后马上送入图像识别服务建议把图片写入Path.GetTempPath()下的专用临时目录处理完立刻删除。我见过有项目把临时图片堆在程序目录里跑了几个月后磁盘爆掉排查半天才发现是没人清理临时提取的帧。5.4 与C#上位机框架集成时的线程模型建议热词里有一堆关于C#上位机、WinForms卡顿、Task用法的内容正好和本文场景重叠。如果你是在上位机项目里做帧提取有一个起码的线程模型建议FFmpeg的进程调用绝对不要放在UI线程里执行哪怕你只是想提取一帧。UI线程做一次进程等待意味着界面在这个等待周期内完全无响应鼠标移动都不流畅。用户会以为程序崩溃了实际上它在后台解码。我在WPF项目里通常的做法是把ExtractFrameAsync通过Task.Run丢到后台UI线程用await等待结果拿到输出路径后再用Dispatcher或Control.Invoke回到UI线程绑定到图片控件。在WinForms里还有个小坑await之后的代码默认回到UI线程但如果你用了ConfigureAwait(false)代码会在线程池线程继续执行这时直接访问控件会抛跨线程异常。控制好ConfigureAwait(false)的使用范围只在真正不需要回到UI上下文的库内部方法里使用对外暴露的方法保持原有await语义。6. 进阶技巧与工程化经验总结6.1 用FFprobe探测视频信息再决策参数光有帧提取还不够很多时候你需要先拿到视频的基本信息才能决定提取策略。FFmpeg工具包里的另一个命令行工具ffprobe就是干这个的。C#里调用ffprobe和调用ffmpeg一样都是进程模式但输出是文本解析起来需要一点技巧。简单场景可以用-show_format和-show_streams参数输出JSON格式的信息然后反序列化到C#模型public class VideoInfo { public double? Duration { get; set; } public int Width { get; set; } public int Height { get; set; } public double? Fps { get; set; } public string? CodecName { get; set; } } public async TaskVideoInfo ProbeVideoAsync(string videoPath) { var startInfo new ProcessStartInfo(GetFfprobePath()) { UseShellExecute false, CreateNoWindow true, RedirectStandardOutput true, RedirectStandardError true }; startInfo.ArgumentList.Add(-v); startInfo.ArgumentList.Add(quiet); startInfo.ArgumentList.Add(-print_format); startInfo.ArgumentList.Add(json); startInfo.ArgumentList.Add(-show_format); startInfo.ArgumentList.Add(-show_streams); startInfo.ArgumentList.Add(videoPath); using var process Process.Start(startInfo)!; string stdout await process.StandardOutput.ReadToEndAsync(); await process.WaitForExitAsync(); // 解析JSON ... return videoInfo; }拿到视频时长后可以做均匀取帧的策略比如固定取视频时长的0%、25%、50%、75%、100%各一帧这个逻辑用在视频预览图生成上非常有效。拿到分辨率后也可以动态决定是否需要缩放合理配置scale参数。6.2 硬件加速与显卡解码帧提取的性能瓶颈在解码部分如果你的目标机器有NVIDIA显卡或集成了Intel Quick Sync可以考虑让FFmpeg走硬件解码路径。这个过程会显著降低CPU负载尤其是批量提取大量高分辨率视频时。NVIDIA硬解加在-i前面使用-hwaccel cuda -hwaccel_output_format cudaIntel Quick Sync的话是-hwaccel qsv。但注意硬件解码器不是所有编码格式都支持H.264和H.265基本都行AV1在较新的显卡上也逐步支持了。硬件解码模式下部分视频滤镜比如scale也需要配合硬件格式做调整处理起来比纯软件稍复杂。我的建议是先纯软件实现跑通业务流程确认帧提取质量和性能满足要求后再考虑上硬件加速做优化。千万不要一上来就开硬件加速不然遇到滤镜和像素格式的兼容性问题时排错成本会让人抓狂。6.3 错误日志与可观测性最后分享一个工程习惯。FFmpeg的stderr输出是排查问题的第一手资料一定要把它记录到日志里。我在封装里返回一个包含stderr字符串的错误信息但有时候FFmpeg退出码为0但输出文件却不存在这种诡异情况光看错误码是不够的需要把stderr全文打印出来才能定位。因此我在实际项目中会维护一个日志队列把每次调用的输入视频路径、目标时间点、FFmpeg参数列表、耗时、退出码、stderr尾部几百个字符都记录下来。上线后一旦有用户反馈提取失败翻日志就能快速定位是视频文件问题、参数问题还是资源不足问题。这种做法在给多个产线部署上位机软件时尤其重要因为现场的机器环境和你本机不可能完全一致视频源也是五花八门。6.4 我个人的一些补充体会在所有框架和封装之上我想提醒各位的是FFmpeg的命令行参数虽然看起来只是字符串但它背后是强大的滤波和流处理语义。同样是-ss放在不同位置性能差10倍同样是输出jpg-q:v的取值不同在视觉模型里的表现可能有明显差异。我见过有人为了省事把所有视频帧都按默认质量输出结果下游的OCR识别率下降了好几个百分点原因居然只是图片压缩得太狠导致文字边缘糊了。这种问题靠调代码解不出来得回到参数本身去理解。还有一点如果视频源是网络摄像头或者流媒体地址帧提取之前先确认网络稳定性。我踩过最离谱的坑是摄像头输出RTSP流时偶发性丢包导致FFmpeg报Packet loss然后退出后来又换了一个输出格式为MJPEG的摄像头问题才彻底消失。视频帧提取这件事跨度很大不光是代码层面的工作视频源本身的特性也决定了整个方案的成败。7. 最后再分享一个小技巧收尾处我再给一个很多人不一定知道的实用技巧如果你只需要提取特定时间点附近的帧但又担心关键帧对齐导致时间点偏差太大可以在快速定位之后再做一次精确微调。具体命令是先-ss放前面快速跳转到目标点之前约1秒的位置再在-i后面加一次-ss精确到目标时间点。这样既利用了快速定位减少解码量又保证了时间点精度是生产环境里比较理想的折中方案。ffmpeg -y -ss 00:01:22 -i input.mp4 -ss 00:00:01 -frames:v 1 -q:v 2 output.jpg这段命令中第一个-ss负责把解码起点推近到第82秒第二个-ss再从第82秒开始精确解码到第83秒。实测下来对2小时的视频这种组合方式比单纯把-ss放-i后面快几十倍同时输出帧的时间点误差控制在毫秒级。类似的组合思路在FFmpeg的很多场景里都能举一反三核心就是理解参数求值顺序和流处理节点的关系。关于C#和FFmpeg的帧提取我能分享的实战经验大概就是这些。这个组合看起来简单但做深了涉及解码原理、进程调度、并发控制、参数语义各个层面每一步都有不少细节值得琢磨。希望这篇拆解能帮你在自己的项目里少走几个弯路把视频帧提取这个基础组件做得又稳又快。