Marked.js 中的上下文泄漏问题与最佳实践

在 Marked.js 这个流行的 Markdown 解析库中，开发者可能会遇到一个性能陷阱：当重复使用 walkTokens 函数时，会导致解析时间逐渐增加。这种现象表面上看起来像是内存泄漏，但实际上是由于库的设计机制导致的预期行为。

Marked.js 默认采用全局作用域来维护扩展功能。每次调用 marked.use() 方法时，都会向内部维护的处理器列表中添加新的函数。这意味着如果在循环或频繁调用的函数中重复添加 walkTokens 处理器，会导致处理器列表不断增长，从而影响解析性能。

对于需要动态处理 token 的场景，比如国际化翻译等需求，推荐以下两种解决方案：

1. 全局单例模式：在应用初始化时一次性注册处理器，通过外部变量维护状态。这种方式性能最优，适合大多数场景。

2. 实例化模式：使用 Marked 类创建独立实例。虽然每次创建新实例会有轻微性能开销，但能确保处理逻辑的隔离性，适合需要动态配置的场景。

特别需要注意的是，在翻译等需要收集文本的场景中，应该通过外部变量（如示例中的 translations 对象）来维护状态，而不是通过重复注册处理器来实现。这种设计既符合 Marked.js 的性能优化原则，也能避免潜在的内存问题。

理解这些机制对于开发高性能的 Markdown 处理应用至关重要。正确的使用模式可以充分发挥 Marked.js 的解析性能，同时避免不必要的资源消耗。