Ferrite - 小而美的跨平台 Markdown 编辑器!

小白在逛 GitHub 时发现的一款新开发的,简洁清新的 Markdown 编辑器,下载尝试了一下,感觉良好,特此前来推荐给小伙伴们!:grinning_face_with_smiling_eyes::grinning_face_with_smiling_eyes::grinning_face_with_smiling_eyes:

2026年1月18日,最新消息,Ferrite 的界面已经支持国际化了,我昨天将其翻译为简体中文,今天开发者就已经引入了。感兴趣的小伙伴可以下载最新版本测试测试,看看有哪些地方还需要改进的!可以在这个帖子中或者直接去 GitHub 上反馈的。

首先给出项目的 GitHub 主页:GitHub - OlaProeis/Ferrite: A fast, lightweight text editor for Markdown, JSON, YAML, and TOML files. Built with Rust and egui for a native, responsive experience.

这是 Ferrite 的项目进展与未来规划: Ferrite/ROADMAP.md at master · OlaProeis/Ferrite · GitHub

据开发者自己的介绍,此项目代码 100% 由 AI 生成,旨在探索 AI 辅助开发的发展潜力。

就像项目简介上的介绍一样,这个项目是用 rust+egui 编写的,相比以往常见的庞然大物 Electron 来说,可谓是小巧玲珑,即使和 tauri+webview 来说,也不遑多让。

虽然说是 Markdown 编辑器,但它也可以当作一个纯文本编辑器的,它除了 Markdown 之外,还支持40余种格式的语法,当下作者已经支持完善的有 YAML、TOML、JSON这些数据格式,代码格式方面的支持还在改进当中。

应用是一个单文件,只有一个 exe 执行程序,因为是编辑器,所以可以把 md 文档拖拽到应用上打开,也能直接把它设置为默认应用(已经计划在下个版本实现此功能)。

目前功能虽然还很简单,但是对现代系统的支持相当完善。主题跟随系统,支持语法高亮、图表功能、所见即所得、多标签、行号、行宽自定义、代码折叠,以及代码地图、目录大纲,这些基本都是一个优秀的编辑器必备的功能!

界面和 Obsidian 一样,支持源代码视图、所见即所得的即时渲染视图、分栏视图,这三种视图都支持双向编辑。而且还有无干扰模式,支持自定义字体,中文排版段首缩进(下个版本完善)等,并且计划添加支持插件功能。在一个只有 10m 大小(版本0.23的应用体积)的文件内,实现这么多功能,可真不简单啊!

注:Ferrite本身就是参考 Obsidian 开发的,Obsidian 是黑曜石,Ferrite 则是铁素体(晶体结构), 单词源自拉丁语ferrum(意为“铁”)+ite(矿物的后缀)的结合形式。

这是我自己的截图:

下面是项目开发者的截图:

最后附上 copilot 对 rust+egui 的介绍如下:

Ferrite 不是用 Tauri/WebView;它是用 Rust + egui/eframe 原生绘制 GUI 的本地应用。
因此可编译成“单文件”可执行程序(没有单独的浏览器子进程或 WebView2 进程),也不会在任务管理器里看到 system webview 相关的外部进程。
项目里还有专门用 Rust 实现的 Mermaid 渲染(pure-Rust、直接用 egui 绘图),并未嵌入 JavaScript 渲染引擎。
egui/eframe 是直接在应用进程内用 GPU(wgpu/glow/backends)或系统窗口系统绘制 UI,不会启动浏览器子进程或嵌入 WebView2 运行时,所以任务管理器只会显示单个 Ferrite 可执行进程(和正常的 GPU 驱动、系统 DLL),看起来就是“单文件可执行”。
现代 webview 应用会有 HTML/CSS 渲染的特征(比如使用大量 Web 字体、CSS 风格、html 元素行为、依赖浏览器特性),而 egui 的 UI 风格是 immediate-mode 原生绘图,交互/渲染逻辑在 Rust/egui 层完成。Ferrite 的代码(src/*)也实现了许多 GUI 逻辑(editor widget、minimap、mermaid widget 等),这说明 UI 是用 egui 直接实现的,而不是网页/JS。

昨天发现的时候,因为有字体方面的缺陷,不支持 CJK 字体,所以就去反馈了相关 bug,在其他用户的协助下,开发者今天解决了这个问题。既然已经没有重大 bug 了,所以就想着推荐给小伙伴们尝尝新!

不过还需要注意的是,在 Windows 11 上运行应该是没有问题的,但是在我的 Windows 10 上,出现了窗口错位的现象。如果是 Windows 10 的小伙伴,可以稍等等,等开发者解决问题了,再去尝试的。

窗口显示错误的原因已经找到并解决了,是我默认使用的核显导致的。当我切换为独显后,Ferrite 就恢复正常了。这个不是 Ferrite 的 BUG,是我自己的问题,唉!看来又到了更新电脑的时候啊…

1 个赞

Win 7可以用吗?

1 个赞

没测试过,不过考虑到这些新技术的话,应该是不支持的…:sweat_smile::sweat_smile::sweat_smile:

1 个赞

能不打开文件夹的前提下多标签编辑嘛?
能所见即所得地编辑嘛

1 个赞

这么丑的界面, 很难相信是ai开发的

3 个赞

等新版本发布吧,这些是在0.3.0版本的计划中的。:blush::blush::blush:

Markdown 最大的问题不是兼容html标签吗?这样原生的编辑器也需要浏览器引擎来渲染

这个可以上项目反馈区咨询的,开发者很热心的,有问必答的,而且还把未来的开发蓝图做出来了,正在慢慢完善中,例如未来还有计划添加ASCIIDOC语法。有相关的需求可以去和开发者提的,编辑器还支持各种插件功能的。:grinning_face_with_smiling_eyes::grinning_face_with_smiling_eyes::grinning_face_with_smiling_eyes:

向 AI(百度·文心一言) 提出如下问题:

为什么 Rust + egui/eframe 在 几MB 的体积内就能实现 上百MB 甚至 快上GB 体积的 Electron 和 tauri+webview 的功能呢?Rust 究竟有什么神奇之处呢?
难道 Electron 就做不到吗?还是说 Mozilla 在浏览器相关领域的开发经验远超 Google?所以才会使得 Rust 只要很少的一段代码就能实现 blink 的功能呢?

AI(百度·文心一言)回答如下:

Rust + egui/eframe 能在几 MB 内实现 Electron 或 Tauri 数百 MB 甚至 GB 级别的功能,核心原因并非 Rust 有“魔法”,而是架构选择的根本差异:Rust 直接编译为原生二进制,而 Electron/Tauri 嵌入了完整的浏览器引擎。

:rocket: 核心差异:原生渲染 vs 浏览器封装

  • Rust + egui/eframe:
    egui 是一个纯 Rust 编写的即时模式 GUI 框架,它不依赖任何 Web 技术。所有 UI 绘制、布局、事件处理都在本地内存中完成,最终编译为单一原生可执行文件(通常 2–10 MB),无外部依赖。它用 CPU 渲染像素,性能高效,内存占用极低。

  • Electron / Tauri + WebView:
    Electron 嵌入了完整的 Chromium 浏览器(含 V8 引擎、Blink 渲染器、网络栈、JavaScript 引擎等),即使一个空窗口也需加载数 MB 的浏览器运行时。Tauri 虽用 Rust 后端,但前端仍依赖系统 WebView(Windows 上是 Edge Chromium,macOS 是 WebKit),体积仍被浏览器引擎主导。一个最小 Tauri 应用通常在 20–50 MB,复杂应用轻松超 200 MB。

:magnifying_glass_tilted_left: Rust 的“神奇”之处是什么?

Rust 的优势在于:

  • 零成本抽象:高性能的内存管理与编译期检查,让开发者能写出接近 C/C++ 的速度,却拥有现代语言的安全性。
  • 静态链接:所有依赖被编译进单一二进制文件,部署简单,无运行时依赖。
  • 无垃圾回收:避免运行时 GC 停顿,响应更流畅,适合桌面 GUI。
  • 跨平台编译:一次编写,可编译为 Windows、macOS、Linux 原生应用,体积可控。

:warning: 注意:Rust 并没有实现 Blink。你提到的“Rust 很少代码实现 Blink”是误解。egui 完全不使用 Blink、Webkit 或任何浏览器引擎。它是一个自研的 2D 渲染器,功能聚焦于构建高效、轻量的桌面界面,而非兼容 HTML/CSS/JS 的完整 Web 平台。

:cross_mark: Electron 就做不到吗?

Electron 本身不是为轻量化设计的。它的目标是让 Web 开发者能快速构建跨平台桌面应用,牺牲体积换取开发效率和生态兼容性。你不能指望用 Chrome 做一个 5MB 的计算器应用——它天生就带着整个浏览器。

:globe_with_meridians: Mozilla vs Google?浏览器经验不是关键

Mozilla 的 Gecko(Firefox)和 Google 的 Blink(Chrome)都是成熟的浏览器引擎,但这与 egui 无关。egui 不是浏览器,它不解析 HTML,不执行 JavaScript,也不渲染 CSS。它是一个图形库,类似 Qt 或 GTK,只是用 Rust 实现。它的轻量源于功能范围的精准控制,而非浏览器技术的优劣。

:white_check_mark: 总结:选择取决于你的需求

需求 推荐方案
轻量、快速启动、低内存、原生体验 Rust + egui/eframe(5–10 MB)
复杂 UI、Web 技术复用、丰富生态(如图表、富文本) Electron / Tauri(100–500+ MB)
需要 HTML/CSS/JS 交互或 Web API Tauri(Rust 后端 + WebView 前端)
不需要 Web 技术,追求极致性能与体积 Rust + egui

Rust 的“神奇”,是系统级语言 + 精准设计 + 零抽象开销的组合成果,不是魔法,而是工程智慧。


如果你正在开发一个工具类桌面应用(如配置器、数据查看器、本地工具),不妨尝试用 eframe 快速搭建一个 5MB 以内的原型,体验原生 GUI 的流畅与轻盈。

我很讨厌小而美,比如某信,真是垃圾到不能再垃圾的IM

2 个赞

@Qingwa 推荐这个上下主站 虽说还在快速开发中,但是已经可以日常使用了。轻量、开源、便携免安装,可以说当下的极佳选择了。

1 个赞

还是别了,

我用的Google输入法, 甚至无法打字, 第一次遇到这种情况
它甚至连稳定的UI都没有, 打开1分钟不到UI就崩了
虽然硬盘占用小, 但是它内存占用大啊, 内存占用是QOwnNote的三四倍
完全无法使用的状态
还是别给别人添乱了

你说的崩溃情况我从来没遇到过,大哥你是什么配置啊?:hushed_face::hushed_face::hushed_face:
egui 本身在中文输入法上支持是不太行,但是只是候选框错位和退格会多退一步而已,但 ferrite 的开发者已经决定了在 0.3.0 版本放弃使用 egui 内置的编辑器,改用自己开发的编辑器来解决这个问题。
我用的 rime-weasel 在 ferrite 上面编辑内容,一直都是正常输入的,没有见过不能使用的情况。谷歌输入法已经停更很多年了吧,不支持新技术的话也不算什么问题的。Windows 是用 dmp 文件来储存程序故障日志的,你可以用 everything 查找一下,提交相关的故障文件给开发者看看是什么情况。
内存占用大这个问题,开发者也已经列入了待改进计划中了,要在 0.3.0 版本将内存占用降到 100m~150m 内。而且相比其它的采用 Electron 或者 tauri+webview 开发的 Markdown 编辑器的内存占用,这个也不见得是个问题。
Qownnotes 是基于 QT 开发的,内存占用低、软件体积小确实是它的优势,但它是笔记应用,和纯粹的编辑器是两种不同的应用。它应该和 Obsidian 或者同样基于 QT 的VNote 来比较的。同样的框架,VNote 的内存占用甚至比 Qownnotes 还低。

软件在快速迭代中,有bug可以先更新最新版本再提issues,开发者也很重视cjk用户

我使用Windows11+小狼毫同样可以正常打字。
楼上也有陈述,在Electron大行其道的当下,内存。200的占用已经不是值得一提的问题,个人体验软件已经比使用的前md工具zettlr markText强出一截

UI显示有问题,文字显示不正常,win10

关掉所有窗口重开一下试试,不要开着多个窗口。

如果不行参考我的截图的选项位置切换一下语言试试

如果还不行盲操作换下这2个选项

1 个赞

感谢提供解决方案,我这边只要设置这里就够了:


但现在的问题是,怎么只有设置界面是中文的?程序主界面还是英文。

仓库所有者不是中国人。程序上周刚增加了国际化支持,需要社区贡献来进一步完善。

2 个赞

Win10Pro
GooglePinyinInstaller_x64_3.0.1.98.exe
你自己装一个就能复现了