这个笔记记录一下在我的博客的知识页做过的优化。

知识页的问题分成两类：

1. 包体积过重
2. 阅读体验不够连续

这两类问题其实都很影响真实使用体验。

1. Markdown、代码高亮和 Mermaid 必须按需加载

知识页的重包问题，本质上不是 Markdown 本身，而是“Markdown 生态能力一把全带上来”。

最开始比较重的链路是：

• markdown-renderer
• 代码高亮
• Mermaid
• Mermaid 的图表内核

如果这些能力都在初始阶段一起进来，那么即使用户打开的是一篇没有图表、没有代码块的普通文档，也会被迫承担额外成本。

后来的处理方式是分层懒加载。

a. Markdown Viewer 懒加载渲染器

只有真正打开文档时，才去加载 Markdown 渲染相关代码。

b. 普通代码块命中时，再加载代码高亮

如果文章里没有代码块，就不必把代码高亮能力一并带上来。

c. 命中 mermaid 代码块时，再加载 Mermaid

Mermaid 继续保留自动渲染，但只有真正遇到 ```mermaid 代码块时才动态加载对应组件和图表内核。

这一轮调整之后，markdown-renderer 的构建产物大约从 1.1 MB 压到了 325 KB 左右，而 mermaid.core 依然有大约 585 KB，但它已经变成“命中图表时才进来”的成本，而不是所有文档统一承担的成本。

2. 手机端导航滚动手感优化

知识页除了包大小，还要考虑阅读过程中的细节体验。

移动端的知识页侧边栏如果带明显惯性，体验会偏“飘”，尤其是在抽屉式面板里更明显。

因此这里额外做了一层处理，让滚动更跟手，避免明显的甩动感。

这类问题不会体现在构建产物体积里，但对日常使用的影响很直接。

3. 记录用户上次阅读状态

知识页现在会记录：

• 上次打开的是哪一篇笔记
• 那篇笔记的阅读进度

下次刷新后，如果这篇笔记依然存在，就直接恢复到原来的文章和原来的滚动位置。

这样用户继续阅读时不需要重新找文件，也不需要重新拖到上次的位置。

4. 处理异常状态

阅读状态持久化还有一个很重要的细节：不能盲信旧记录。

如果上次打开的那篇笔记已经被删除了，那么刷新时就不应该继续强行恢复。

这里的处理方式是：

1. 先用当前文件树校验本地记录
2. 如果文件还在，就恢复到原来的文章和进度
3. 如果文件已经不存在，就清掉失效记录并回到空状态

这样知识页不会落到错误内容上，也不会因为旧记录失效而表现异常。

总结

知识页这类页面的优化，不能只看 bundle size。

真正完整的优化应该同时覆盖：

• 初始加载成本
• 图表与代码块的按需能力
• 移动端交互手感
• 阅读状态连续性

只有这几层一起处理，知识页才会从“能用”变成“顺手”。