必须用 web worker 解析 markdown，因其是 cpu 密集型任务，主线程解析万字文档易卡顿超 100ms；worker 提供独立线程，配合预编译实例、功能裁剪和结构化通信，实现不阻塞交互的实时渲染。
直接在主线程解析 Markdown 容易造成界面卡顿，尤其面对万字文档或实时预览场景。把解析逻辑移入 Web Worker 是最有效、最成熟的解耦方案——它让渲染完全不阻塞用户交互，真正实现“输入即响应”。
为什么必须用 Web Worker？
Markdown 解析本质是 CPU 密集型任务：词法扫描、AST 构建、插件遍历、HTML 生成。即使使用 marked 或 markdown-it 这类高性能库，在处理 50KB+ 文档时，主线程仍可能冻结 100ms 以上，触发浏览器的“页面未响应”警告。Web Worker 提供独立线程环境，天然隔离计算压力，是纯前端高负载渲染的底线保障。
核心架构：三端通信闭环
Worker 不是黑盒，它需要与 UI 层保持低延迟、结构化通信：
- 主线程 → Worker：发送原始 Markdown 字符串 + 配置对象（如是否启用 GFM、代码高亮语言、数学公式开关）
-
Worker → 主线程：返回标准化结果对象，包含
html字符串、toc目录数组、stats（解析耗时、节点数等） -
错误兜底：Worker 内部捕获所有异常，返回带
error字段的响应，避免主线程崩溃
Worker 内部如何高效解析？
不是简单把 markdown-it 丢进去就完事。关键优化点在于：
-
预编译解析器实例：Worker 启动时初始化一次
new MarkdownIt(...)，复用其内部规则表和缓存，避免每次调用重复构造开销 -
禁用非必要功能：关闭
html: true（前端渲染不需执行脚本）、breaks: false（换行由 CSS 控制），减少 AST 节点数量 - 增量解析支持（可选）：对编辑器场景，可设计 diff 协议，仅将光标附近变更段落送入 Worker，跳过未修改区域
实际集成要点
避开常见坑，才能稳定落地：
-
Worker 文件必须独立 JS 文件：不能是内联字符串或模块动态导入（Safari 旧版不支持）；推荐用
new Worker(new URL('./md-worker.js', import.meta.url)) -
禁止跨域加载依赖：所有解析库（如 markdown-it）需提前打包进 Worker 脚本，或使用
importScripts同步加载本地副本 - 内存控制：对超长文档，Worker 中主动限制递归深度或节点总数，防止栈溢出；返回截断提示而非静默失败
-
React/Vue 组件封装建议：用
useMemo或computed缓存 Worker 实例，配合AbortController支持取消上一次未完成的解析请求
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
