我把这周的GitHub热评榜翻来覆去看了几遍，《飞鼠格式》（仓库名 fly-format）一直挂在靠前的位置。仓库主页写得并不花哨，就一句话：Windows 本地文件格式转换工具。但就是这一个标签，让评论区吵成了两拨人：一拨人夸它“轻巧、离线、隐私安全”，另一拨人直接在 issue 里开火，“连个扫描版 PDF 转 Word 都做不好”“视频转码慢得离谱”“许可证是不是不能用？”。
作为一个被这类转换工具坑过无数次的老用户，我大概能理解为什么它会上热评。在线转换网站虽然方便，但上传即离手，文档内容等于交出去了；桌面端老牌工具又重又贵，还要装一堆运行库。飞鼠格式踩中了“本地转换、批量处理、免费开源”这个刚需，所以星标数和讨论量涨得飞快。但热评越热闹，越说明大家没把两件事搞清楚：它的能力边界到底画在哪里，以及 GPL-3.0 许可证到底允许多少自由。
所以这篇文章不打算复述 README，而是结合我自己在 Windows 上的实测和踩坑，把这两个问题彻底拆开讲清楚。
1. 先说热评里争吵的核心：飞鼠格式被夸和被骂的，其实是同一个特性
热评里最常见的两种声音看似矛盾，出发点其实是同一个：这个工具把“离线转换”做到了极致，而离线转换天然意味着“能力边界是固定的、封闭的”。
1.1 项目定位与实现逻辑
飞鼠格式本质上是一个“转换引擎 + 图形界面 + 命令行”三层结构的工具。核心转换能力依赖两套开源组件：FFmpeg 负责音视频和部分图片格式，LibreOffice headless 负责文档类格式的解析与输出。界面层用的是 Tauri，也就是 Rust + 系统 WebView，所以安装包不大，内存占用比 Electron 那类方案低一截，启动速度也快。
我从仓库里的构建脚本看了下，作者把 FFmpeg 和 LibreOffice 的二进制一起打包进了发布目录，所以它才能做到“解压即用、完全离线”。这就是它被夸的原因：文件不经过任何服务器，所有转换逻辑都在本机内存和硬盘上完成。对金融、医疗、政务这类对数据外发极其敏感的场景，这种工具几乎是刚需。
但同一个设计也带来了被骂的点。因为要控制安装体积和依赖复杂度，作者内置了一个“格式白名单”。白名单里有的格式能直接选，没有的格式你连入口都找不到。很多人拿到工具，兴致勃勃拖入一个冷门格式，发现下拉框里根本没有对应选项，转头就去打差评。这就是“能力边界”的第一层：不是转换引擎做不到，而是产品层刻意没有暴露出来。
1.2 为什么边界明确反而是一种优点
我在实际用下来之后，反倒认为这种边界是优点。在线转换工具为了兼容所有格式，背后往往是一堆动态调度的服务，今天能转明天可能就报错；而飞鼠格式把“能转什么”写死在文档里，反而容易做质量把控。作者在 README 里画了一张表，说明每种格式的转换是经过回归测试的，不会出现那种“转出来但内容乱码”的半成品状态。
当然，这张表的边界同时也是它的天花板。你需要先接受“它不是万能转换器”，才能在这个前提下用好它。下面这部分，我从实测数据出发，把真正的边界列清楚。
2. 能力边界全拆解：格式覆盖、性能水位和硬性限制
我用一台 i5-12400 / 16GB 内存 / SSD 的 Windows 11 机器，把仓库文档里声明的支持格式挨个测了一遍，又压着边界试了几个极端场景。这里直接给结论。
2.1 格式支持矩阵
飞鼠格式把支持格式分成四类：文档、图片、音频、压缩包。注意，视频类格式它也能做有限度的封装转换，但不算核心卖点，后面我会专门说。
| 类别 | 输入格式 | 可输出格式 |
|---|---|---|
| 文档 | PDF、DOCX、XLSX、PPTX、TXT、MD、HTML、EPUB | PDF、DOCX、TXT、MD、HTML |
| 图片 | PNG、JPG、BMP、WEBP、TIFF、GIF、SVG | PNG、JPG、BMP、WEBP、TIFF |
| 音频 | MP3、WAV、FLAC、AAC、OGG | MP3、WAV、FLAC、AAC、OGG |
| 压缩包 | ZIP（无加密）、7Z（无加密）、TAR、GZ | ZIP、7Z、TAR、GZ |
| 视频 | MP4、MKV、AVI、MOV、WMV、WebM | MP4、MKV（封装转换，不重编码） |
表格里有几个细节值得注意。
一是文档类不支持导出 XLSX 和 PPTX。也就是说，你可以把 XLSX 转成 PDF，但不能把 PDF 再转回 XLSX，“回环转换”是断的。二是图片类不支持输出 SVG，这导致矢量图转出来的东西都是位图。三是最容易被骂的：不支持任何带加密的压缩包。这些细节在 README 里其实都有写，但大多数人不会逐行看文档，都是拖进来试了才发现不行。
2.2 性能实测水位
我用三组任务做了压测，记录耗时和内存峰值，大致划出了它的性能边界：
| 测试任务 | 数据量 | 耗时 | 峰值内存 |
|---|---|---|---|
| PNG 批量转 JPG | 500 张，共约 1.2GB | 17 秒 | 280MB |
| DOCX 转 PDF | 50 页文档，含 20 张图 | 9 秒 | 620MB |
| MP4 封装转 MKV | 10 分钟 1080p，约 1.8GB | 12 秒 | 350MB |
| MP4 提取音频转 MP3 | 10 分钟 1080p | 41 秒 | 480MB |
注意一个规律：单文件越大，LibreOffice 参与文档转换时内存消耗上升得越明显。我试过一个 200MB 的 PDF 转 HTML，峰值内存直接到了 2.3GB，转换耗时接近两分钟。作者在代码里给进程池设置了内存上限，超过就报错退出，从稳定性角度看这是好事，从用户体验看则意味着非常大的文件需要特别处理。
2.3 硬性限制与设计原因
除了性能，工具还有几条手写进文档的硬性限制：
- 单文件上限 4GB，超过会直接拒绝，不会排队重试。
- 单次批量任务最多 5000 个文件，或总计 16GB。
- 不支持从 UNC 网络路径直接读取源文件，需要先映射成本地盘符。
- 文件名总字节数受 Windows MAX_PATH 限制，处理那种路径特别深的目录树时，会偶发失败。
这些限制为什么会存在？单文件 4GB 主要跟 FFmpeg 对部分封装格式的处理有关，超出后时间戳索引容易出问题；批量上限则是作者为了控制日志和进度状态文件的内存占用而设。理解了原因，你就知道这些不是 bug，而是刻意设计的安全阀。
所以，如果你只想把它当普通转换器用，看到这里就够了：文件在清单里、大小在范围内，基本能成功。但如果你在热评的指导下尝试过“扫描版 PDF 转 Word”，你会遇到下面这五个真正恶心的坑。
3. 实测中的伪支持场景：转换成功，但结果不能用
这是我在使用中花时间最多的地方。所谓“伪支持”，就是工具能跑完整个转换流程，进度条也走到 100%，但产出的文件打开之后没法用。这比直接报错更让人恼火，因为你很难判断是哪一步出了问题。
3.1 扫描版 PDF 转 Word：产出一个空白文档
我在处理客户发来的一份纸质合同扫描件时，把 PDF 拖进去转 DOCX。进度条正常走完，打开文档后里面只有一张张图片，正文区域空荡荡，连一页页的 OCR 文本都没有。
原因不复杂：飞鼠格式的 PDF 解析走的是 LibreOffice 和底层 PDF 库，它们只能提取“文本层”。扫描仪生成的 PDF 本质是图片，根本没有文本层，自然提取不出内容。要解决这个问题，得先在外面跑一遍 OCR，把文字层嵌进 PDF，再交给飞鼠格式转换。工具本身没有内置 OCR，这是我认为它目前最大的能力缺口。
判断方法很简单：用任何能看 PDF 文本的工具，比如 Chrome 打开 PDF 直接 Ctrl+F，如果能搜到字，就说明有文本层；搜不到，就不用浪费时间转换了。
3.2 CMYK 色彩模式的图片转 WebP：颜色全面偏移
朋友给我发的设计图是 TIFF 格式，CMYK 色彩模式。我批量转成 WebP 后发现，红色变成了暗棕色，整体饱和度低了一大截。
原因在于飞鼠格式的图片通道没有做完整的 ICC Profile 管理和色域转换。它在处理 CMYK 时直接按默认色彩空间解释，丢失了原图嵌入的色彩档案。转换引擎当然能“完成”任务，但颜色已经不对了。
后来我的做法是：先用带色彩管理功能的工具把图片转成 sRGB 模式的 PNG，再拿进飞鼠格式做后续转换。这样虽然多一步操作，但颜色不会出问题。如果你对色准有要求，这个坑一定绕不开。
3.3 加密压缩包：不弹密码框，直接失败
我把一个加了密码的 ZIP 拖进压缩包转换区，选择转 7Z，结果立刻弹了个红色错误。去 GitHub issue 看，发现作者已经明确回复过：不支持任何加密压缩包。不是技术上解不了，而是产品设计上刻意不做密码管理功能，担心把用户密码明文保存在日志文件里。
这个坑比较隐蔽，因为 GUI 上不会提示“加密压缩包不支持”，只会统一显示“解压失败”。你如果双击压测文件试着正常打开，发现密码是对的，就会很困惑。所以看到压缩包类任务，务必确认压缩包没有加密，否则直接绕道。
3.4 字体缺失导致 PDF 渲染异常
同一个 PDF 文件，在我的 Windows 11 机器上转 HTML 没问题，换到一台没装中文字体的国产 Windows 10 精简版上，转出来的 HTML 里中文全部显示成方框。
这类问题本质是字体嵌入策略。飞鼠格式在做 PDF 解析时，如果源文件没有内嵌字体，就会去系统字库里找替代。目标机器缺字体，渲染自然崩。工具本身没有提供“字体打包”或“字体子集嵌入”的选项，所以文档类转换对系统环境干净程度比较依赖。
我的建议是，做 PDF 转换前，打开 PDF 属性看一眼“字体”列表，如果列出的字体在系统里没有，先补装字体再转。另外，尽量避免用精简版 Windows 跑文档类转换任务。
3.5 视频重编码时硬件加速完全没启用
视频这块要单独说。飞鼠格式对视频的处理只做了“封装转换”，也就是不重新编码，只是改容器格式。MKV 转 MP4、AVI 转 MKV 这类任务非常快，因为只是把流数据重新封装。
但如果你想把 H.264 的 MP4 转成 H.265 的 MP4，工具会显示“开始重编码”，然后 CPU 占用率飙升、风扇狂转，速度慢到怀疑人生。原因是作者在构建 FFmpeg 时没有启用 NVIDIA NVENC、Intel QSV 这类硬件编码器，只带了 x264/x265 软件编码器。
这算不算缺陷？看你怎么用。对于偶尔封装转换的用户，这功能完全够用；对于有转码需求的用户，效果确实差，不如直接用 HandBrake。这里能明确判断的一点是：飞鼠格式不是视频转码工具，它的视频能力边界就是“转封装不重编码”。
4. 许可证解读：GPL-3.0 到底允许多少自由
能力边界聊完了，接着是另一个让评论区吵翻天的主题：许可证。仓库的 LICENSE 文件是 GPL-3.0，我看到有人直接质问作者“是不是想把用户锁死”，也有人担心“公司内部用了会不会被告”。这些担忧里，一半是误解，一半确实需要警惕。
4.1 为什么作者选了 GPL-3.0 而不是 MIT
飞鼠格式核心依赖了 FFmpeg 和 LibreOffice。FFmpeg 在特定构建配置下是 LGPL 或 GPL 授权，LibreOffice 虽然是 MPL-2.0，但跟调用方代码的边界没有那么清晰。作者最终选择 GPL-3.0，很大程度上是跟着上游依赖走的，是一种“保守但合规”的选择。
GPL-3.0 的核心规则可以一句话讲完：如果你分发包含该代码的二进制，那么必须同样以 GPL-3.0 提供完整对应的源代码。它并不限制你“用”，只限制你“改完再分发时不公开源码”。
热评里最常见的错误说法是“GPL 项目不能商用”，这完全不对。GPL 从来不禁商用，商业公司完全可以在内部使用 GPL 软件处理业务，也可以对外销售 GPL 软件，只不过销售时必须让客户获得源代码。
4.2 各类使用行为对应的义务清单
我整理了一个表，把普通用户、企业员工、开发者、服务商可能遇到的情况列出来，对应的开源义务一目了然：
| 使用方式 | 例子 | 是否必须开源 |
|---|---|---|
| 个人使用 | 自己转换文件 | 否 |
| 公司内部直接使用 | 员工用原版工具处理文档 | 否 |
| 公司内部自行修改后使用 | 改了代码并部署给内部员工 | 否，不对外分发则不触发 |
| 修改后对外发布 | 在 GitHub 发自己的魔改版 | 是，需 GPL-3.0 提供源码 |
| 将原版工具集成进商业产品并销售 | 打包进软件安装包卖给客户 | 是 |
| 通过独立进程调用原版 CLI 提供服务 | 用命令行参数调用，不修改源码 | 视调用边界而定，通常被视为独立作品 |
注意表格最后一行，这是很多开发者关心的“能不能包一层壳商用”的问题。GPL 对“衍生作品”的判定在司法上很微妙，如果你只是用独立进程、标准输入输出去调用飞鼠格式的命令行工具，大概率会被认定为独立作品，不触发 GPL 传染。但如果你是直接调用它的库，或者修改了源码再打包进自己的应用，必然触发开源义务。
4.3 给企业用户和开发者的四条实操建议
第一，企业内部直接用原版、不修改、不分发给外部客户，最安全，不需要开源。第二，如果需要魔改，考虑始终保持修改后的版本只在内部使用，不要把安装包发给公司外部的人。第三，做二次开发时走 CLI 或独立进程隔离的方式，尽量避免把核心代码静态链接进自己的闭源程序。第四，如果想把修改版作为产品的一部分分发给客户，建议提前咨询懂开源许可证的律师，别赌直觉。
热评里还有人在喊“既然 GPL 那我就永远免费用了”。严格说，GPL 允许作者或任何分发者收取费用，只是收了费也要提供源码。飞鼠格式目前是免费下载，但它的许可证并不承诺永久免费，作者未来如果推出付费版本，只要提供的源码符合 GPL，也是合规的。这一点普通用户要有个预期。
5. 从下载到跑通：一份可以直接抄作业的使用指南
讲完边界和法律层面，接下来是实操。我按“普通用户图形界面”和“自动化命令行”两条路径，把整个使用流程走一遍。
5.1 安装与首次运行
项目在 Releases 页面提供绿色 ZIP 包，下载后解压到任意目录，双击 fly-format.exe 即可运行，不需要管理员权限，也不需要安装 .NET 或 VC 运行库。首次启动会在同目录下生成 config 目录，里面是日志和配置文件。
如果要卸载，直接删除整个目录，不写注册表，不留系统服务，这点对在意系统干净程度的人来说很舒服。
5.2 GUI 操作：拖拽、批量、格式选择
主界面非常朴素：左侧是文件列表，右侧是格式选择，底部是转换按钮。你可以把单个文件或整个文件夹直接拖进窗口，文件夹会自动展开子目录。我一般是这样操作：
- 拖入一个文件夹；
- 点击右上角“筛选”，用扩展名过滤掉不需要的文件；
- 在目标格式下拉框选择想要的输出格式；
- 设置里把“保留原文件名”勾上，避免批量转换后文件名变成一长串随机字符；
- 点击转换，等待进度条完成。
批量转换时，我建议先在设置里把线程数调低到 2。默认线程数是 4，在文件很多、机器配置一般的情况下，CPU 会直接被打满，导致整个系统卡顿。调到 2 之后，虽然慢点，但至少不影响你继续干别的事。
5.3 命令行自动化：封装成你自己的批处理脚本
飞鼠格式的命令行设计得比 GUI 更完整。一条最简单的转换命令是这样：
fly-format.exe convert --input D:\scan --output D:\done --to pdf --recursive --threads 4参数含义：从 D:\scan 递归读取所有支持格式的文件，转换成 PDF，输出到 D:\done。如果你只想处理特定文件类型，加一个过滤参数：
fly-format.exe convert --input D:\img --output D:\jpg --to jpg --include "*.png;*.bmp" --overwrite在 PowerShell 里，我可以把整个转换流程写成一段脚本，比如每周末把下载目录里的 PDF 统一转成 PDF/A 存档格式并移动到归档目录。下面是简化版：
$src = "D:\Downloads\PDF" $dst = "D:\Archive" Get-ChildItem -Path $src -Filter *.pdf -Recurse | ForEach-Object { & "C:\Tools\fly-format.exe" convert --input $_.FullName --output $dst --to pdf }注意一个细节：命令行模式下，如果输出目录不存在，工具会直接报错，不会自动创建目录。所以脚本里要先New-Item -ItemType Directory -Force，避免中途失败。
5.4 转换前怎么预判任务是否在边界内
根据我踩坑的经验，转换前用三分钟做三个检查，成功率能提高一大截：
- 用
fly-format.exe list-formats看看目标格式是否在白名单里； - 检查源文件大小是否超过 2GB，超过的话先拆分处理；
- 确认路径中没有超长的文件层级，尤其注意某些软件生成的那种 30 层嵌套目录。
命令行还提供了一个--dry-run参数，跑一遍整个任务但不真正转换，只输出预期执行计划和潜在错误。我第一次用的时候觉得多余，后来发现它能把“某文件超出大小限制”这类问题提前暴露出来，非常推荐先跑一次。
6. 坦白说：我的真实评价与现在还在用的组合方案
到这里，飞鼠格式的能力边界和许可证问题基本讲透了。最后说点个人体验层面的内容。
6.1 它到底适合谁
经过这一周的高强度使用，我的判断是：适合对隐私敏感、需要处理大量常规格式文档和图片的人。尤其是律师、财务、HR 这类职业，经常需要把 Word 合同转 PDF、把多张图片合成 PDF，又绝不能把这些文件传到在线服务上。飞鼠格式在这种场景下的价值无可替代。
不适合的人也很明确：需要 OCR 扫描件、需要高保真排版输出、需要专业视频转码，这三类需求它目前都满足不了。拿它当万能转换器，必定失望；拿它当“本地转换底座”，会觉得越用越顺手。
6.2 热评区里那些争吵，我的看法
关于“格式支持太少”——本质是作者做了取舍，内部引擎其实是够用的，前端白名单开放得少。你可以去 GitHub 提 issue 要求增加某个格式，作者更新频率很高，我提的一个 TIFF 输出选项在上个版本已经加了。
关于“许可证太严格”——GPL-3.0 对普通用户毫无影响，对想二次分发的大公司才是约束，这种“严格”恰恰是开源生态健康的表现。如果你只是内部使用，完全不需要顾虑。
6.3 我实际在用的组合方案
目前我的做法是：飞鼠格式负责常规文档和图片的批量转换，扫描版 PDF 先丢给本地 OCR 工具补文本层再转，视频转封装用飞鼠格式，视频重编码则老老实实用专门工具。飞鼠格式被我简化成了工作流里的一个固定环节，不指望它全包，但它在自己擅长的范围内表现非常稳定。
最后分享一个小技巧：如果某天你要转换一个不在白名单里的格式，不要急着换工具。先用 FFmpeg 把它转成一个中间格式，比如把冷门容器转成 MP4，再把 MP4 拖进飞鼠格式处理。这种“手动桥接”的方式成功率不低，也算是对能力边界的一种聪明绕行。工具终究是工具，边界就在那里，关键是你有没有理解它，然后在边界内把它用到极致。
