Milkdown编辑器性能优化：解决Slugify计算导致的文档操作延迟问题

问题背景

在基于Milkdown构建的富文本编辑器中，开发者发现了一个严重的性能问题：当处理中等或大型文档（约150KB）时，初始粘贴内容和编辑操作会出现显著延迟。在MacBook Pro M1设备上，150KB文档的初始加载（粘贴）需要约15秒时间，编辑操作也存在明显卡顿。

问题定位

通过性能分析工具追踪，发现问题根源在于频繁调用@sindresorhus/slugify模块的计算。进一步调查发现：

1. Slugify操作不仅应用于标题节点，而是在所有节点变更时都会触发
2. 每次按键操作都会导致标题ID重新生成
3. 当替换slugify实现为直接返回静态字符串时，性能立即得到显著改善

技术原理

Milkdown使用slugify生成标题ID的主要目的是：

• 为标题创建锚点链接
• 支持多语言场景（包括CJK字符和emoji）
• 确保ID的唯一性和可读性

然而，当前实现存在两个关键问题：

1. 计算范围过广：slugify操作被应用于所有节点变更，而不仅仅是标题节点
2. 计算频率过高：每次编辑操作都会触发ID重新生成

解决方案

开发者提供了两种可行的解决方案：

1. 快速修复方案

通过配置headingIdGenerator，直接使用节点文本内容作为ID：

import { headingIdGenerator } from '@milkdown/preset-commonmark';

this.crepe.editor.config(ctx => {
  ctx.set(headingIdGenerator.key, value => value.textContent);
  // 其他配置...
});

这种方法完全避免了slugify计算，性能提升显著，但会牺牲一些ID的规范性和唯一性保证。

2. 长期优化方案

Milkdown维护者正在考虑以下改进方向：

• 实现一个更轻量级的slugify替代方案
• 优化ID生成策略，减少不必要的计算
• 实现更智能的缓存机制，避免重复计算

性能优化建议

对于需要处理大型文档的项目，建议：

1. 评估需求：如果不需要复杂的标题锚点功能，可采用快速修复方案
2. 按需计算：只在真正需要生成标题ID时执行slugify操作
3. 延迟计算：对于初始加载，可以考虑分批或异步执行ID生成
4. 缓存结果：对未修改的标题节点复用已有ID

总结

Milkdown作为一款优秀的编辑器框架，在处理大型文档时暴露出的性能问题提醒我们：即使是设计良好的工具库，在实际应用场景中也可能需要针对特定用例进行优化。开发者应当根据自身需求，在功能完整性和性能表现之间找到平衡点。

对于大多数应用而言，简单的文本内容作为ID可能已经足够；而对于需要严格ID规范的场景，则可以等待官方优化的轻量级slugify实现。理解底层机制并根据实际需求进行定制，是使用任何开源框架的最佳实践。