wevm/ondine

如果你的文档页为了画几张 Mermaid 图而在浏览器里加载解析和布局代码，Ondine 把这一步挪到构建阶段，最终输出静态 SVG。对在意页面体积的静态站点和文档作者值得一看，但它还是个很年轻的项目，支持范围也有限。

解决什么问题

文档作者在 Markdown 里写一段 Mermaid 时序图或流程图，站点在每次访问时用浏览器端渲染器解析、布局并绘出 SVG。这样能用，但渲染器体积不小，还要在客户端执行，图表出现前可能造成布局跳动。Ondine 把这一步换掉：图表由 Rust 工具链提前编译，页面只用一个很小的运行时挂载已经生成的 SVG。结果就是浏览器拿到的是成品图表，而不是“请先画一张图”的指令。

有什么不同

Ondine 的核心选择是“先编译、后展示”。Vite 插件把 .mmd 导入编译成构建期 SVG，CLI 可以从文件或标准输入编译，Node 编译器把同一条渲染路径提供给脚本和服务端。主题使用 --ondine-* CSS 自定义属性，已经编译好的图表可以在不重新编译的情况下切换明暗配色。README 还列出了 Markdown/MDX 的 remark 集成、可选的浏览器端 WASM 编译，以及一个把 URL 中编码的图表渲染成图片的 GitHub Worker。

主要取舍在于，Ondine 不是通用图表引擎。它主张输入与 Mermaid 兼容，而可用模块按“每种图表类型一个或 all 打包”来描述，这意味着支持的图表类型是有限集合，而不是全部 Mermaid 语法。如果你的图表用到集合之外的写法，问题会在编译阶段暴露。构建期模型还意味着图表被打进产物，改外观需要重新构建站点，而不能让客户端重新渲染。

谁值得试

适合已经在用 Vite 或 Node 构建的文档站和博客：Mermaid 图较多，目标是不再向客户端下发体积较大的渲染器。.mmd 导入和 remark 集成让团队不必重写内容就能接入，前提是图表落在已支持的 Mermaid 子集内。GitHub 图片 Worker 是另一条无需构建的路径，适合在 README 里放图。

不适合需要用户在浏览器里交互编辑图表并即时看到结果的场景，也不适合依赖 Ondine 支持范围之外的 Mermaid 特性的团队。README 没有提供兼容性对照表，大规模迁移文档前应先确认图表类型覆盖情况。

使用条件与边界

明显的条件是编译需要 Rust 工具链，以及与 JavaScript 生态的集成点：Vite 插件、Node 编译器、remark 插件和 WASM 模块。README 列出了 Vite 插件、CLI、Node 和浏览器端编译的接入指南，但链接是仓库内的相对路径，建议从项目文档和仓库入手。日常维护包括让编译产物与源文件改动保持同步，并让主题变量和站点 CSS 对齐。

最关键的两条边界：一是兼容性，README 声称输入兼容 Mermaid，但没有列出覆盖的图表类型，只能拿真实图表去验证；二是预编译 SVG 让页面变小，也让图表变成静态内容，交互频繁或经常变化的图表拿不到同样的好处。

HotRepo 点评

截至 2026-10-25 的快照，这个仓库创建仅 6 天，总星数 399，在 Rust 新项目榜（不是总榜）上位列第 15，观测日期为 2026-10-25。这只是年轻项目的一个快照，不是单日增长数据。HotRepo 的存储覆盖里没有可比的每日榜单历史，因此目前无法判断热度能否持续。真要迁移前，先确认 Ondine 支持的图表类型覆盖你文档里已有的 Mermaid 图。