知识管理工具 Obsidian 团队正式发布了一款名为 Pele 的开源图表渲染引擎。该引擎专为解析 Mermaid 语法设计，以夏威夷火山女神命名，主打零外部依赖、仅 230 kB 的体积（Gzip 压缩后比 Mermaid.js 小 6 倍），并将渲染耗时压低至 0.05–0.3 ms，宣称比传统 Mermaid.js 快达 500 倍。
但这绝非一次毫无代价的无痛平替。这套自研引擎之所以能跑出夸张的数据，本质上是用最激进的工程手段对 Mermaid 原生能力进行了大刀阔斧的裁剪与重构。Obsidian CEO Kepano 宣布 Pele 将在 Obsidian 1.15 核心版本及 Obsidian Publish 中正式集成，意味着数百万依赖本地知识库与复杂图表的用户，即将迎来输入流畅度的大幅跃升，同时也必须面对旧图表样式断裂的现实摩擦。
惊人跑分背后的测试玄机与边界
长期以来，Mermaid.js 是 Markdown 生态中事实上的图表规范，但它庞大的身躯（包含 23 个直接依赖）和高昂的重绘开销，一直是实时预览型笔记软件的心头之患。在打字即渲染的高频交互下，几十毫秒的延迟足以产生明显的视觉卡顿。
Pele 支持 Mermaid 12.1.0 版本的全部内置图表，并原生支持基于 CSS 变量的换肤与响应式自适应，甚至将默认支持的流程图连线上限从 Mermaid 的 500 条放宽到了 5,000 条。然而，仔细审视其工程实现，所谓的 500 倍性能神话存在特定语境。
在 Pele 仓库自带的基准测试脚本中，真正的比对对象其实并非 Mermaid.js 本体，而是 Craft 团队此前开源的 beautiful-mermaid。更关键的是，该脚本包含容错机制：当某个渲染器抛出异常时会直接跳过并累计错误计数。这意味着最终跑分建立在过滤了失败样本的基准上，且该脚本并未计入真实浏览器中 SVG 的 DOM 挂载耗时与图形正确性验证。脱离了纯内存计算的实验室环境，实际页面中的体感加速固然明显，却未必如纸面数据那般悬殊。
用断舍离换取速度与安全
为了实现极小体积与瞬时生成，Pele 并没有沿用上游既有的技术栈，而是做了一套自研布局算法。Kepano 明确解释，团队不向上游 Mermaid.js 提交代码，是因为上游必须背负沉重的历史包袱与通用兼容性要求，而 Pele 的第一诉求是极致速度以及与 Obsidian 的深度契合。
这种取舍直接体现为功能层面的主动割裂：
- 彻底封杀 HTML 注入.Pele 明确不支持任意 HTML 标签。这固然规避了复杂的跨站脚本攻击隐患与 DOMPurify 清理负担，却也让那些在节点里嵌入富文本格式的高级用法直接失效。
- 剥离交互能力.Mermaid 原生支持的 JavaScript 点击回调被直接忽略，图表退化为纯静态展示媒介。
- 放弃历史配置继承.Mermaid 积累多年的 themeVariables 配置在 Pele 中无法生效，取而代之的是纯粹的 CSS 变量。
- 排除第三方扩展.诸如 ZenUML 等外部集成插件被全部剔除在外。
对比同样致力于优化排版的竞品 beautiful-mermaid，两者的路径分歧十分鲜明。beautiful-mermaid 依赖成熟的 ELK.js 布局计算并支持终端 ASCII 输出，自带 15 种开箱即用的 Shiki 主题，但仅覆盖 6 种图表且依赖社区插件安装；Pele 则选择将所有图表类型的自研算法打包进核心，追求绝对的内聚与自洽。
速度的飞跃不是技术魔法，而是果断抛弃历史兼容包袱的清障代价。
自立门户带来的生态割裂与迁移阻力
当 Obsidian 在 1.15 版本中用 Pele 替代现有的渲染逻辑时，受冲击最深的是依赖复杂知识图谱的用户群体。
自研布局算法虽然摆脱了外部重型依赖，但也导致节点坐标、连线走向以及间距比例完全脱离了 Mermaid.js 的视觉直觉。原先精心排布的流程图在新引擎下可能会发生明显的折线错位和文本重排。对于视文档为长青资产的重度笔记用户而言，这种排版断裂需要耗费不小的精力去逐一修正。
- 风险.原有笔记中重度依赖自定义 HTML 样式、点击事件脚本和 themeVariables 的图表，在升级到 Obsidian 1.15 后将出现样式损坏或交互失效。
这一动作也清晰展现了 Obsidian 对排版基础设施自主可控的诉求。在边写边看的笔记软件里，渲染引擎早已不再是边缘附件，而是决定交互响应上限的核心命脉。从向上游开源项目提需求、等合并，到索性自立门户造轮子，Obsidian 用一套高专用的工具链巩固了自家的护城河。但这同时也给上游 Mermaid.js 生态敲响了警钟：当核心下游应用为了性能不惜破坏一致性另起炉灶时，通用标准与专属优化之间的裂隙正在越拉越大。