干音视频这行的人应该都有过这种体验需求从来不是按教科书来的。今天要做桌面播放器明天给直播平台搭转码切片后天又接到一个给海量视频批量生成字幕的任务。每个需求单独看都像新问题但拆到最底层你会发现所有人都在同一批开源音视频项目上做排列组合——FFmpeg负责解封装和解码VLC、MPV负责播放渲染OBS负责采集推流SRS、MediaMTX负责服务端分发Audacity、SoX负责音频处理Whisper负责语音识别一环扣一环。所以前段时间我特意挤出一周时间把这几年真正上手评估过、部署过、在生产环境里因为没提前评估而付出过代价的项目按“经典”和“还能继续投入”两个标准筛了一遍最后留下来刚好36款。这篇就把完整清单、分类逻辑、选型思路和踩坑经验一次说清楚。刚入行的新人可以把它当作地图老手也可以对照着查漏补缺。1. 为什么我花时间整理这36个音视频开源项目先说痛点与判断标准1.1 音视频工程是一条又长又碎的链路很多第一次接触音视频开发的人容易把一个项目想得很简单“不过就是播放一个视频、转个码、推个流嘛。”真动手之后才发现完整链路至少包括采集、编码、封装、传输、解封装、解码、渲染、后处理、分发九个大环节每个环节背后还有格式、协议、编码标准这些细分问题。比如一个最简单的直播功能就涉及摄像头或屏幕采集、H.264编码、RTMP或SRT推流、服务端转码、HLS切片、CDN分发、播放器拉流中间任何一段掉链子用户看到的就不是卡顿就是黑屏。更麻烦的是这些环节往往不是同一个团队、同一个技术栈负责的。做客户端的人要处理播放器做服务端的人要处理流媒体服务器做视频平台的还要管转码和存储。一个人如果不主动把音视频领域的开源项目建立成一张“网络”而是等需求来了再去搜很容易搜到一堆过时项目或者被某个看起来很火但协议很坑的项目拖进泥潭。1.2 我筛项目时看的五个硬指标这次筛选并不是简单按名气排列我给自己定了五个指标每个项目都要过一遍维护状态最近有没有正式Release社区是不是还在回答Issue。一个两年没动静的项目除非是FFmpeg这种生态基石否则我基本直接排除。跨平台能力虽然我工作中主要用桌面和服务器但很多项目会落地到手机端、嵌入式或NAS上跨平台决定了以后要不要换轮子。开源协议GPL、LGPL、MIT、Apache的约束差别很大做商业产品的人必须一开始就看清而不是等代码都写完了才发现不能闭源分发。不可替代性有的项目虽然技术老但生态地位摆在那里根本绕不开有的项目虽然有替代品但社区、文档、周边工具差了不止一个量级。组合能力音视频项目很少单独使用能否跟FFmpeg、VLC这些“核心件”良好协作是我很看重的点。这五个指标筛下来上榜的36款不一定是所有开源音视频项目里最“炫”的但一定是实际工程里最容易被用到、也最值得投入时间研究的。2. 36款项目全景一张表分七个方向看清全貌为了避免一上来就陷入细节我先按用途把这36个项目分成七个方向编解码与引擎、播放器、直播与流媒体、视频剪辑、音频工具、封装与字幕、下载与AI。下面这张表就是全景速查项目名后面的描述都尽量压成一句话方便你按照自己的需求先锁定相关类别。2.1 编解码与引擎8个项目项目一句话定位FFmpeg音视频处理的事实标准转码、解码、推流、滤镜全覆盖GStreamer插件化多媒体管线框架适合嵌入式与复杂实时链路x264H.264软件编码器兼容性与编码质量的最佳平衡点x265H.265/HEVC编码器压缩率更高但算力消耗更大libvpxVP8/VP9编码库在浏览器与WebRTC生态里有天然优势LAMEMP3编码的事实实现转MP3绕不开它Opus现代开源音频编码标准低延迟高质量FLAC无损音频编码与命令行工具音乐归档的标配2.2 播放器6个项目项目一句话定位VLC全平台万能播放器也能作为libVLC嵌入到自己的应用MPV从MPlayer重写而来的现代播放器脚本能力极强Kodi客厅媒体中心遥控器体验和插件生态很成熟IINAmacOS上的现代播放器界面和系统习惯很贴近SMPlayerMPV的前端封装配置记忆与字幕功能对普通用户友好MPlayer老牌播放器技术影响力深远但现在架构偏老2.3 直播与流媒体7个项目项目一句话定位OBS Studio推流与录屏的事实标准直播场景的起点SRS功能全面的开源流媒体服务器支持RTMP/HLS/SRT/WebRTCMediaMTX轻量流媒体网关偏协议转换与边缘部署nginx-rtmp经典NGINX流媒体模块配置简单但功能有限ZLMediaKitC高性能流媒体服务框架安防和RTSP场景很强Jellyfin开源媒体服务器管理影音库并负责服务端转码Icecast音频流广播服务器适合网络电台和音频直播2.4 视频剪辑5个项目项目一句话定位Shotcut基于MLT框架的跨平台剪辑器界面友好适合快速粗剪OpenShot上手极快的简单剪辑工具适合少量轨道项目Kdenlive功能更专业的非线性剪辑工具多轨和关键帧完整Blender三维创作工具内置视频序列编辑器可处理合成与轻剪辑Olive理念先进的编辑器但还在迭代期生产环境需谨慎2.5 音频工具5个项目项目一句话定位Audacity通用音频录制与波形编辑工具降噪、拼接、导出都靠它Ardour多轨录音与混音工作站适合音频工程和音乐制作LMMS开源电子音乐制作工具适合编曲和Loop创作SoX命令行音频处理瑞士军刀批量转换和效果处理极高效Sonic Visualiser音频可视化分析工具适合做语音研究和质量观察2.6 封装与字幕3个项目项目一句话定位HandBrake开源批量转码工具预设丰富适合压缩和格式转换MKVToolNix无损封装混流工具包改封装、加字幕不重新编码Aegisub专业字幕编辑工具ASS特效和卡拉OK字幕都靠它2.7 下载与AI2个项目项目一句话定位yt-dlp活跃的视频下载工具能拉取主流站点的视频与字幕Whisper开源语音识别方案转写、翻译、生成时间戳都可以这张表把36个全部列完了。实际使用时我的经验是普通用户重点装VLC、HandBrake、Audacity、Aegisub、MKVToolNix就基本够日常使用开发者则要优先吃透FFmpeg、GStreamer、libmpv、OBS、SRS这五个项目几乎是其他音视频项目的地基。3. 编解码与多媒体引擎FFmpeg 和它的伙伴们构成的地基3.1 FFmpeg不只是命令行工具更是行业标准可以这么说你现在能接触到的绝大多数音视频软件底层都在某个位置调用过FFmpeg。它提供了一整套完整的解决方案包括libavcodec、libavformat、libavfilter、libswscale、libswresample等模块分别负责编解码、封装解析、滤镜处理、图像缩放、重采样这些事。很多人认识FFmpeg是从命令行开始的。最基础的转码是这么写的ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 23 -c:a aac output.mp4-crf 23是H.264编码的质量控制参数数值越小码率越高画质越好23是一个兼顾画质和体积的常见起点。如果你只是想截图做封面ffmpeg -i input.mp4 -ss 00:01:00 -frames:v 1 thumbnail.pngFFmpeg更强大的地方在于滤镜链比如先缩放分辨率再统一调节对比度亮度ffmpeg -i input.mp4 -vf scale1280:720,eqcontrast1.1:brightness0.05 -c:a copy output.mp4做服务端转码和推流时它又是另一副面孔ffmpeg -re -i input.mp4 -c copy -f flv rtmp://your-server/live/stream-re表示按原速读取输入避免推流时瞬间把数据全读出来。这条命令在本地直播测试里非常常用。作为库嵌入时FFmpeg的路径就更复杂一些打开输入、找到流、初始化解码器、循环读取包、解码出帧、处理完再编码封装。这套流程几乎每个音视频工程师都要亲手走一遍。我的建议是做工具优先用命令行做产品优先用库但都要注意编译配置FFmpeg的构建方式决定它对外是LGPL还是GPL这会直接影响商业软件的合规风险后面第八章我会专门展开。3.2 GStreamer以“插件管线”的方式思考音视频和FFmpeg那种一把瑞士军刀式的设计不同GStreamer的核心思路是“管线”。你可以把不同功能的元素像乐高一样拼接起来元素之间通过Pad连接多个元素组成Bin一条完整的处理链路就是Pipeline。用命令行工具gst-launch-1.0可以直观感受这种思维。播放一个视频只需要gst-launch-1.0 filesrc locationinput.mp4 ! decodebin ! autovideosinkfilesrc读取文件decodebin自动选择并调用解码器autovideosink自动选一个窗口把画面显示出来。箭头!就是元素之间的连接符。GStreamer的优势在于它天生面向复杂实时链路开发视频会议客户端、车载多媒体系统、嵌入式图形应用时你可以把采集、前处理、编码、传输拆成一个个插件运行期动态调整链路。它的语言绑定也比FFmpeg更友好Python、Rust、C都有成熟接口。选型上我的判断是如果你只需要一个独立的转码/处理流程FFmpeg就够了如果你要长期维护一个会不断演化、需要插入新处理模块的系统GStreamer的管线模型会让你后期好过很多。它最大的坑是插件版本匹配问题系统自带的插件和项目里单独编译的插件经常互相打架后面我会再提到。3.3 六款经典编解码器各自的正确打开方式项目/编码器支持的编码格式最大特点典型场景x264H.264软件编码成熟兼容性和画质平衡极好直播转码、VOD分发x265H.265/HEVC压缩率高但编码计算量明显变大4K归档、高码率存储libvpxVP8/VP9浏览器和WebRTC生态友好网页播放、实时通信LAMEMP3MP3高质量编码的事实标准批量转MP3、车载音乐OpusOpus延迟低、音质好自适应码率能力强语音会议、实时音频FLACFLAC无损压缩解压后和源文件完全一致音乐归档、无损分发选编码器时不能只看压缩率还要看兼容性成本。x264的H.264是全网兼容性最好的选项几乎所有设备都能硬解所以直播场景我基本固定用它。x265的HEVC压缩率确实好适合点播平台做高清文件归档但低码率下如果参数没调好画面细节容易糊而且老设备硬解支持不完整。libvpx的VP9在Web生态里很吃香大多数现代浏览器都能直接播放自适应流媒体场景里常用它配合DASH。LAME现在主要受众是车载系统、老式MP3播放器这类只认MP3的地方。Opus则是实时通信的王牌从延迟到音质全面领先语音会议类应用基本闭眼选。FLAC没什么好争论的——你需要无损归档音乐就是它没有之一。还有一点提醒软件编码和硬件编码的选择不是简单的“软编画质好、硬编速度快”。新代显卡的硬件编码器质量已经相当可以但不同品牌、不同代显卡的编码效果差异很大。我的习惯是先跑一轮同码率对比实测再决定生产链路里用哪套。4. 播放器项目从桌面到客厅的四种体验路线4.1 VLC、MPV、MPlayer三代播放器的技术基因与取舍MPlayer是最早影响整个播放器生态的项目之一很多后来的播放器都直接或间接继承了它的代码。它短小精悍至今仍有维护但渲染方式、脚本机制相对陈旧现代开发我不太建议从它起步了解历史时倒是很好的标本。VLC的强项是“完整成品”。它的核心是模块化架构内置了几乎所有常见格式的解码器不用用户另装解码包跨平台覆盖Windows、macOS、Linux、Android、iOS。它提供的libVLC库也可以嵌到你自己的应用里适合需要“一个开箱即用的完整播放能力”的产品。缺点是对深度定制不太友好UI体系偏传统。MPV是从MPlayer和mplayer2重写出来的现代播放器。它保留了命令行和脚本化的灵魂支持Lua、JavaScript脚本GPU解码、色彩管理、画面增强这些现代特性都非常激进。很多新桌面播放器干脆就直接把MPV当内核自己只写一个壳。通过libmpv接入你自己的应用是目前最推荐的播放器嵌入路径。如果让我给一个快速判断要完整桌面播放器直接用VLC要在自己的App里嵌入播放窗口优先libmpv想研究现代播放器技术的底层实现源码啃MPV。4.2 Kodi、IINA、SMPlayer不同场景下的播放器答案Kodi是完全为客厅媒体中心设计的核心交互是遥控器不是鼠标键盘。它管理本地媒体库自动刮削封面和简介还有庞大的插件体系既可以当家庭影音库的前端也能搭配NAS组成一套完整的家庭影音系统。对普通用户来说把Kodi装在电视盒上再接一个移动硬盘比折腾其他方案省心得多。IINA是macOS用户的好选择。它基于MPV但界面和交互完全按照macOS习惯来做支持画中画、系统媒体快捷键、Touch Bar还有相关设备这些系统特性。如果你在Mac上工作IINA基本是默认播放器的最优解。SMPlayer的定位则更偏向“家庭默认播放器”。它的经典功能是记住每个文件的播放位置下次打开自动续播还集成了字幕在线搜索对不懂技术但需要字幕的家人朋友非常友好。从开发角度这几款播放器也能看出一个规律播放器项目的差异化已经不在“能不能解码”而在于“能不能管理媒体库、能不能脚本扩展、能不能贴合某个平台的操作习惯”。5. 流媒体服务器推流、转码、分发链路里的主力们5.1 OBS Studio一切直播和录屏的起点OBS Studio是我见过的开源项目里完成度最高的之一。它把直播这个复杂动作拆成了清晰的层次场景、源、滤镜和输出。你可以把不同的摄像头、窗口、图片作为“源”放进同一个场景再给每个源挂滤镜做调色、裁剪或遮罩最后统一推流或录制。它的虚拟摄像头功能也很有用把OBS输出伪装成一个摄像头设备任何软件都能直接调用。对开发者来说OBS最有价值的是可编程控制能力。通过内置的WebSocket接口外部程序可以动态切换场景、调整源、控制推流开始与停止这为自动化直播、远程控制播控台提供了很好的基础。很多演唱会现场、课程直播推流工具底层都是OBS加一层自动化脚本。一个比较容易被忽略的细节是编码器差异。同样写着NVENC不同代显卡的硬件编码器能力差别很大AMD和Intel的硬件编码器也各有特点。部署直播主机时不要只看接口支持要实际推一段快速运动的画面看暗部是否大范围糊掉。5.2 服务端四选择SRS、MediaMTX、nginx-rtmp、ZLMediaKit服务端选型是整个流媒体链路里最要花心思的因为直播延迟、并发能力和协议支持都跟它直接相关。项目协议覆盖特点适合场景SRSRTMP/HLS/HTTP-FLV/SRT/WebRTC功能全面文档贴近实际部署直播平台、低延迟WebRTC直播MediaMTXRTSP/RTMP/HLS/WebRTC/SRT等轻量重点是协议转换与接入边缘节点、嵌入式、IoT场景nginx-rtmpRTMP/HLS配置简单但功能较基础老架构、简单推流需求ZLMediaKitRTSP/RTP/RTMP/HLSC高性能安防生态强监控项目、传统安防、GB28181场景SRS是目前很多直播团队从零起步的首选它把RTMP收流、转HLS、HTTP-FLV输出、SRT弱网推拉流、WebRTC低延迟播放都整合在一起配置量和复杂度也控制得比较好。如果产品定位是“面向大众用户的直播”我基本会先用SRS把整条分发链路搭出来。MediaMTX的优势是极轻量单二进制文件就能跑主要工作是做协议转换。比如把RTSP摄像头流转成RTMP或HLS或者把WebRTC拉流接到RTSP源上。它在边缘节点、弱网嵌入设备上很吃得开。nginx-rtmp是很多老项目的遗迹。它跟NGINX集成方便配置也简单适合快速验证和低并发场景。但真要面对动态转码、多种协议分发、高并发下线就会觉得处处受限。今天的新项目我一般不会推荐它作为主力。ZLMediaKit则更偏专业流媒体服务特别在安防监控领域优势明显。它内置了RTSP/RTP的完整处理能力对GB28181这类国标协议集成也成熟。做服务器端的高性能流媒体处理系统时它比SRS更贴近C底层开发者。5.3 Jellyfin与Icecast媒体库与音频广播的特殊角色Jellyfin做的是“个人媒体服务器”你把电影、剧集、音乐、照片放进NAS或一台服务器它负责整理媒体库、刮削封面和简介并在客户端播放时按需转码。它所有客户端都开源服务端转码能力也够家庭使用。如果你想把家庭里的影音素材集中管理Jellyfin是目前完整度最高的开源方案。Icecast则是网络音频广播领域的老牌项目。它稳定、轻量、资源占用小主要承担“把一个音频流同时广播给大量听众”的任务。社区电台、校园广播、音频直播这类场景Icecast加一个IceS编码器就能跑得很稳。6. 剪辑、调音、字幕与封装后处理工具链一盘棋6.1 五款开源剪辑工具的定位差异开源剪辑工具的格局比较明朗Shotcut的定位是快速粗剪界面直观时间线简单适合给自媒体做快速编辑OpenShot的上手门槛最低但大型项目和复杂时间线稳定度一般我建议只在小项目里用Kdenlive是功能更完整的专业非线性剪辑器多轨视频、音频曲线、关键帧、字幕轨道样样都有访谈类、教学类、中长视频项目我会优先选它Blender的视频序列编辑器虽然只是它众多功能的一部分但如果你本来就用Blender做三维动画顺手用VSE把成品拼出来流程非常顺Olive的设计理念很现代目标直指专业级剪辑但还没完全打磨到生产级稳定我现在的态度是观望。如果要从工程角度看Shotcut基于MLT框架Kdenlive大量使用FFmpeg的能力两者都可以作为“如何把开源多媒体组件拼成一个完整产品”的学习案例。6.2 音频五人组Audacity、Ardour、LMMS、SoX、Sonic VisualiserAudacity是音频处理的“日常主力”。录音、剪辑、降噪、格式转换、音量归一化这些基础操作它都做得顺手插件生态也够用。我做播客节目或音频降噪时第一反应就是打开Audacity。Ardour更偏向“录音工程和混音台”。它有完整的轨道路由、总线、混音器、自动化曲线适合录制乐队现场、做多轨混音。它的学习曲线明显比Audacity陡但需要的专业控制能力它都有。LMMS是音乐创作方向适合用MIDI和采样做电子音乐、Beat和旋律编排。它对专业DAW的场景做了大幅简化但该有的钢琴卷帘、效果机架、混音器都不缺。SoX是命令行里的音频瑞士军刀。批量把几百个WAV转成MP3、统一响度、降采样一条脚本就能跑完for f in *.wav; do sox $f normalized_${f} norm -3 donenorm -3把峰值归一到-3dBFS批量处理音频素材时特别常用。Sonic Visualiser是音频分析工具可以把波形、频谱图、音高曲线叠在一起观察。做语音研究、音频质量评估、或者排查音频故障时它比Audacity的视图精细得多。6.3 HandBrake、MKVToolNix、Aegisub转码、封装、字幕三件套这三者经常作为一个组合出现。Aegisub负责“做字幕”它的强项是ASS格式支持精确到毫秒的时间轴、特效标签、卡拉OK模式。MKVToolNix负责“封装”它不重新编码只是把视频流、音频流、字幕流重新打包成MKV命令行用mkvmergemkvmerge -o output.mkv video.mp4 subtitles.assHandBrake负责“出片”把封装好的MKV转成目标格式同时控制体积和画质HandBrakeCLI -i input.mkv -o output.mp4 --encoder x264 --quality 22一个完整的工作流是Aegisub校对时间轴并制作ASS字幕 → mkvmerge把原始视频和字幕混流成MKV → HandBrake根据分发平台要求压缩成MP4。需要提醒的是ASS字幕里的字体如果没有嵌入换到别的设备播放时会变成替换字体甚至乱码所以最后转码前最好确认字体已经嵌入。MKVToolNix也支持字体附件可以把选定的字体一起封装进MKV里。7. 下载与AI识别音视频工具的新增长点7.1 yt-dlp素材获取环节的实用工具yt-dlp是最流行的开源视频下载工具也是早期youtube-dl项目的活跃分支。它不只是“下载视频”还能获取字幕、缩略图、元数据、章节信息也支持通过--write-auto-subs自动抓取字幕。最常见的用法是选流合并yt-dlp -f bestvideobestaudio --merge-output-format mkv URL这条命令会分别拉取最高画质视频和最高音质音频再用FFmpeg把它们封装成MKV。它在很多自动化媒体采集任务里相当于“素材管道”抓取之后接FFmpeg和Whisper就可以做后续处理。需要特别强调边界这个工具提供的是技术能力使用时要遵守目标站点的服务条款和内容授权规则个人信息、传播范围都要自己把好关。技术是中性工具但使用场景必须合规。7.2 Whisper开源语音识别如何进入音视频流水线Whisper是目前开源语音识别领域影响最大的方案之一。它支持多语言转写、翻译和时间戳输出而且对语音的强项是直接生成带时间轴的文本天然适合做视频字幕。一条比较完整的AI字幕流水线可以这么搭先从视频里抽出16kHz单声道音频ffmpeg -i video.mp4 -vn -ar 16000 -ac 1 audio.wav然后交给Whisper转写并导出SRT字幕whisper audio.wav --language zh --task transcribe --output_format srt拿到初步字幕后再用Aegisub校对断句、打轴和术语比纯手工做字幕快很多。模型大小方面tiny和base适合快速粗略转写small和medium是速度和准确度的平衡点large系列准确率最高但对显存和耗时要求也高。长视频建议先切成10-20分钟的片段分批转写再合并不然内存占用和失败重跑的成本都比较难控制。8. 协议、依赖与兼容性把36个项目放进实际工程前要看的门道8.1 开源协议是第一个筛选器很多人选型时只盯着“功能全不全、口碑好不好”却把协议放在最后看这是很危险的习惯。我见过不止一个项目代码写到一半才发现核心库是GPL做闭源商业分发时会引入额外的开源义务。协议一句话特点对闭源商用最需要注意的是GPL强传染性分发产品时通常要把涉及的衍生代码开源LGPL对动态链接较友好动态链接通常可保留闭源修改库本身仍需开源MIT/Apache宽松可闭源保留版权声明Apache还自带专利授权条款FFmpeg和MPV、VLC这些项目都带有GPL相关组件实际是否触发GPL义务跟你的编译参数、链接方式、是否修改源码都有关系。我的建议是商业产品立项前一天先整理一张“依赖协议表”把每个组件的协议、链接方式和潜在合规风险写清楚后面能省去大量麻烦。8.2 依赖地狱与版本编排心得音视频项目最经典的坑就是“换一个FFmpeg版本原本好好的代码编译不过了”。因为几乎所有的音视频工具链最终都会绕回FFmpeg、OpenSSL、ZLIB这些底层依赖而FFmpeg在版本升级时经常调整API和ABI旧的应用跟着升级往往要改一大片代码。我自己的处理习惯是这样的如果是做工具脚本直接用官方发布的静态编译版不用自己从零编译如果需要在平台里集成一定要把依赖版本锁死并记录对应版本号如果在CI里构建把包含依赖的基础镜像固定下来而不是每次都拉latest。因为一次“顺手升级FFmpeg导致整个转码服务崩溃”的教训我现在对依赖升级的态度就是没有明确的性能或功能诉求不做无谓升级。8.3 看似经典但接入要谨慎的项目我列一份“谨慎清单”主要是想提醒大家“经典”不等于“适合现在接入”。MPlayer技术历史价值很大但现代渲染和脚本生态明显不如MPV新项目没必要走回头路。nginx-rtmp存量部署非常多但功能边界很浅遇到WebRTC低延迟、多协议分发就力不从心。新项目优先考虑SRS或MediaMTX。Olive虽然理念很新但项目成熟度还不足以支撑重负载生产项目可以先跟踪学习不要贸然作为主力剪辑工具。HandBrake的某些老旧预设新版本里很多预设已经过时建议直接自己给参数而不是迷信预设。筛选任何一个开源项目时可以先看最近一次Release时间、提交频率、对主流平台的CI结果以及Issue区是不是一堆“长时间无人回复”的积压问题。音视频领域尤其怕停更项目因为编码标准、硬件平台、系统API都在变停更意味着早晚会被生态甩开。最后分享一点整理过程中的真实体会这36个项目一开始我以为最花时间的是“列出项目名”真正展开之后才发现对比协议、API边界、维护状态和相互组合方式才是最耗精力的部分。而最有价值的产出并不是那张表格本身而是把项目串成流水线的能力——FFmpeg配SRS做直播分发OBS配合ZLMediaKit做监控接入Whisper配Aegisub做AI字幕每一条链路都是几个开源项目协作的产物。所以我的建议是别把这36个当作孤立的工具清单把它当成一套可以拼装的零件库。下次遇到音视频需求先别急着从零造轮子翻翻这里面哪几个能组合出最优解大概率最难的坑已经有人替你填平了。