有的人学算法靠刷题有的人靠看教科书里那张静态的伪代码图还有人靠B站上别人录好的演示视频。但真到自己写代码、跑测试、对着输出结果反推每一步发生了什么的时候总有一种很强烈的割裂感——算法是动态的而教材、笔记、编辑器都是静态的。我一直在想能不能直接在一个写文档的环境里把算法执行过程“播放”出来。于是就有了这个项目一个内置23种算法动画可视化能力的Markdown编辑器。这个东西说白了就是——你在Markdown里写算法代码块编辑器自动识别然后把它跑成一步步的动画直接展示在文档里。不用切换窗口不用录屏不用额外装一堆可视化依赖。写笔记的时候顺便看动画讲思路的时候直接指着动画说非常适合教学、自学、写技术博客这些场景。这篇文章我会把这套东西从设计思路、算法动画的底层实现、23种算法的分类与适配方案到编辑器集成时的关键细节再到实际运行中遇到的坑完整拆开讲一遍。如果你也想做类似的东西或者想在项目里加一个“算法可视化”模块这篇应该能帮你省不少时间。1. 为什么我非要做一个“编辑器内播放算法动画”的东西先说说动机。这个项目不是凭空想出来的是我在准备算法教学材料时被逼出来的。1.1 现有方案到底差在哪当时我调研过市面上已有的算法可视化工具大概有三类独立的算法可视化网站比如VisuAlgo、Algorithm Visualizer动画好看但只能看它预设好的几个例子。你想换成自己的测试数据或者把算法改一版看效果基本上做不到。IDE插件/调试器能看到变量值变化但那是一行一行指令级的视角和“算法步骤”完全是两个粒度。调试器看的是代码状态不是算法逻辑。录好的教学视频最省事也最死板。视频里那个数组长度是固定的你想看20个元素的快速排序重新录吧。这三类方案的共同问题是算法逻辑和文档内容是完全分离的。你写一篇讲解KMP算法的博客文字是一段代码是一段而动画在另一个网站里——读者的注意力在三个地方来回跳。1.2 Markdown编辑器是个天然的载体我后来意识到Markdown编辑器才是一个理想的可视化容器。原因有三条第一Markdown本身就是“内容 代码 展示”的混合体。一篇算法博客既有大段讲解又有代码块如果还能在代码块旁边直接嵌入对应的算法动画整个文档就成了一个可交互的教学课件。第二Markdown的代码块语法天然适合做“标记”。比如在语言标识符里写上algorithm:quickSort解析器就能识别出来——这是要对快速排序做可视化。语法上几乎零侵入。第三编辑器的运行环境浏览器本身就是一个完备的动画渲染平台。Canvas、SVG、requestAnimationFrame全都有不需要额外搭运行时。所以项目目标就很清晰了做一个Markdown编辑器你在里面写一个算法代码块它就能把这个代码跑起来并且用动画展示每一步的状态变化。1.3 为什么是23种而不是5种或者50种算法可视化最怕两种极端。一种是只做两三个“演示型”算法比如冒泡排序和斐波那契看起来很精致但覆盖不了实际教学需求做完就是个玩具。另一种是贪多把数据结构和算法题解全做成可视化结果每种算法的展现形式都浅尝辄止用户根本看不出门道。23种是我反复权衡后的数字。它覆盖了教学和面试准备中最常见的几大类排序8种、字符串匹配3种、图论路径搜索5种、经典动态规划和数值优化7种。每一类都有专属的可视化模型而不是用一种通用模板硬套所有算法。提示做算法可视化时“适配”比“覆盖”重要得多。一个对每种算法精心设计过的30种远比一个对100种算法用同一种方式展示的框架有价值。2. 算法动画的核心机制把一次运行拆成“可控的状态序列”整个项目最底层的设计决策就是动画的驱动力从哪来。我用的是“状态快照流”方案。2.1 状态快照流记录每一次“关键变化”要让一个算法“变成动画”本质上要做的事是捕获算法运行过程中的一系列关键状态然后把它们逐个渲染出来。所以我不试图在算法代码运行时实时渲染动画而是设计了一个两层结构第一层捕获层在算法代码的关键位置埋入snapshot()调用把当前的数据结构状态比如数组、指针位置、节点访问标记记录到一个状态序列里。第二层播放层动画播放器按时间顺序读取状态序列把相邻两个状态之间的差异转化为动画帧渲染到画布上。用一个最简单的冒泡排序举例。原代码大概是function bubbleSort(arr) { const n arr.length; for (let i 0; i n - 1; i) { for (let j 0; j n - i - 1; j) { if (arr[j] arr[j 1]) { [arr[j], arr[j 1]] [arr[j 1], arr[j]]; } } } return arr; }改造后的版本function bubbleSort(arr, snapshot) { const n arr.length; for (let i 0; i n - 1; i) { for (let j 0; j n - i - 1; j) { snapshot({ type: compare, array: arr.slice(), highlighted: [j, j 1] }); if (arr[j] arr[j 1]) { [arr[j], arr[j 1]] [arr[j 1], arr[j]]; snapshot({ type: swap, array: arr.slice(), highlighted: [j, j 1] }); } } } return arr; }snapshot()不返回任何东西它只是把当前的数组快照和元信息这次操作是比较还是交换高亮哪些位置压进全局状态数组。2.2 为什么用“快照切片”而不是直接监听数据变化你可能想问为什么要在代码里手动埋点现代前端框架不是有响应式数据绑定吗直接监听数组变化不行吗我也试过这条路线最后放弃了。原因有三个算法代码是运行在受限环境里的。我为了安全和工作量考虑把用户/内置的算法代码放在Web Worker里执行。Worker里没有DOM也不方便做复杂的响应式代理。监听数据变化只能捕获“值变了”捕获不了“算法意图”。数组位置i和j交换了监听器只知道两个元素值变了但不知道这次变更是“比较后交换”还是“整体旋转”。而动画需要知道这个意图才能决定用什么样的视觉表现——是闪烁一下两个格子还是把一段元素整体推移。快照是显式可持久化的。状态序列可以导出成JSON这份数据既能用于动画播放也能用于性能分析还能在调试时逐帧查看变成一种“算法运行日志”。2.3 快照之间的“差异补间”怎么做连续两个快照之间如果数据变化很大比如快速排序中的partition操作一大段元素都被交换了位置直接硬切会显得非常生硬。我需要把“从状态A到状态B”的过程平滑成动画。这里用到的是经典的**差异补间diff tween**思路对比快照A和快照B找出哪些元素的位置发生了改变、哪些值变了、哪些高亮状态变了。对位置变化的元素计算从旧坐标到新坐标的贝塞尔插值路径。对值变化的元素做一个短暂的缩放/变色过渡。对高亮标记用渐变色光圈替代生硬的背景色块变化。举个具体的例子。快速排序的partition过程把pivot基准值从最右边移到正确位置通常涉及两三个元素的交换。差异补间会捕捉到pivot元素坐标的连续变化然后生成一段从原位置滑到新位置的曲线动画。看动画的人能直观感受到“这个元素在挪窝”而不是“刷一下突然变了个位置”。2.4 快照数量控制不是每行代码都值得记录如果你在算法的每一个循环体里都埋snapshot()记录一个20个元素的冒泡排序会产生将近400条快照。如果其中80%都是“比较后没有交换”那么播放出来会很啰嗦一眼看去全是重复动作。所以我给了快照记录一个简单的过滤逻辑只记录“有实际意义的变化”。比较操作如果比较结果没有触发交换记录一条“轻量级比较”快照用于打高亮闪一下但如果连续10次都是无交换比较就合并成一条“连续比较”快照。交换/赋值操作无条件记录。指针移动如KMP中的i、j游标按移动行程记录连续向同一个方向移动不超过3步的合并为一条。这个优化让动画节奏好了很多。你可以把“播放速度”调快也不会糊成一团。3. 23种算法的分类与专属可视化模型23种算法听起来不少但如果每种都从零写一套渲染逻辑工作量会失控。我的做法是先把算法按“数据形态”分成4类每类设计一套专用可视化模型然后在这个模型基础上做微调。3.1 线性结构类排序与查找8种针对冒泡排序、插入排序、选择排序、快速排序、归并排序、堆排序、二分查找、顺序查找。这类算法的核心数据结构是数组核心操作是比较、交换、移位、划分。可视化模型用**“格子 指针 颜色语义”**来呈现每个数组元素占一个格子格子的高度/宽度与元素值成正比。当前参与比较的元素用黄色边框高亮交换时用蓝色填充。已确定最终位置的元素如冒泡排序每轮结束后沉底的那个渐变为绿色。partition操作中的pivot元素用一个特殊的三角形标记。具体到每个算法我会做几个差异化的调整算法差异化可视化元素归并排序递归层级用垂直分割线显示左右子数组在一个独立轨道上合并堆排序数组上方叠加显示二叉堆的树形结构节点用连线连接快速排序基准元素用皇冠图标标记partition区间用半透明遮罩表示二分查找当前搜索区间用高亮色带标出mid位置闪烁显示3.2 字符串匹配类3种对KMP、Boyer-Moore、Rabin-Karp这三个算法可视化模型要同时展示两个层面的信息模式串在主串上的滑动过程以及内部匹配状态的推进过程。KMP算法的next数组是教学中最容易卡壳的地方所以我把next数组的计算过程单独做了一条展示线。主区域显示主串与模式串的逐位比较每个时刻被比较的字符用光圈圈起来下方区域同步显示模式串对应的前缀表next数组构建过程每填入一个值就高亮对应的前缀/后缀匹配区间。注意KMP里最容易让人困惑的是“失配后j跳到哪”。动画在展示这个跳转时会画一条弧线从失配位置直接指向next[j]的位置同时把跳过的那些字符用半透明状态显示——这样“跳跃”这个抽象概念就被空间化了观众看得见那条弧线。3.3 图论与路径搜索类5种这部分包括BFS、DFS、Dijkstra、A*、拓扑排序。图的可视化模型用的是**“节点 有向边 距离标尺”**布局。节点在画布上按力导向布局算法排布每条边带一个权重标签。算法运行时队列/栈中的节点用一个“待访问列表”浮层实时更新。已访问节点渐变成深色正在处理的节点高亮。Dijkstra/A*会额外显示一个“距离更新动画”和“路径松弛过程”。值得单独说的是Dijkstra的“优先队列变化”展示。很多人在学Dijkstra时困惑于“优先队列到底在做什么”。我在底部嵌入了一个小型的二叉堆可视化面板每次堆顶距离值被弹出时这个堆结构会同步更新并在弹出的节点与堆顶节点之间画一条连接线让观众看到“弹出的是哪个点、更新的是哪些邻居”。3.4 数值优化与动态规划类7种这部分包括粒子群算法PSO、模拟退火、遗传算法、0-1背包、最长公共子序列LCS、爬楼梯、斐波那契。数值优化类算法的可视化模型比较特殊它强调的是“搜索轨迹”而不是“状态变化”。以粒子群算法为例我的实现是在二维平面上生成一堆粒子每个粒子代表一个候选解。算法迭代时粒子在解空间中移动每个粒子的历史最优位置用一个星星标记全局最优用一个更大的光环标记。粒子颜色随适应度值变化适应度高的粒子偏红低的偏蓝。每次迭代结束时记录当前全局最优在解空间曲面上的位置并把最优值的变化曲线绘制在侧边。动态规划类则用经典的**“DP表格 回溯箭头”**模型。0-1背包问题会显示一个二维DP表每填一个单元格就高亮对应行和列并画一条箭头指向依赖的前驱单元格。最终回溯最优解时路径用一条粗线描出非常直观。4. Markdown编辑器侧解析、渲染与交互现在聊聊编辑器本身。这个项目不是重头写一个Markdown解析器而是基于成熟的代码编辑器内核CodeMirror 6外加一个自定义Markdown解析扩展。4.1 用代码块语言标记来指定“要可视化的算法”Markdown代码块的语法是algorithm:quickSort // 这里放快速排序的代码 我扩展了代码块的语言标识符解析逻辑当语言部分以algorithm:开头时这个代码块会被标记为“算法可视化块”。解析流程分四步Markdown解析器照常识别出代码块只是在language阶段捕获冒号后面的算法名。编辑器渲染出代码块的同时在代码块右上角生成一个“播放”按钮以及速度滑块。点击播放时编辑器把代码块里的代码文本传给Web Worker执行器。Worker执行完毕返回状态快照序列动画播放器接管渲染。4.2 编辑器内核为什么选CodeMirror 6对比过CodeMirror 5、Monaco Editor、CodeMirror 6最终选了CM6。原因很实际包体积Monaco太大了光是编辑器核心就接近5MB加上各种语言支持插件能到十几MB。CM6的模块化做得极好只打包需要的部分我压缩后大约300KB。自定义扩展性CM6的“视图插件”体系非常适合做自定义装饰比如在代码块右上角加播放按钮比如改变代码块背景以标示它是算法块。Markdown解析的透明性CM6的Markdown扩展基于lezer/markdown它提供一个完整的语法树我可以非常准确地定位代码块的语言标识符文本范围然后做精准的UI注入。4.3 动画渲染层Canvas还是SVG这个我纠结了很久。最后的结果是两种都用按场景区分。数组、树、图这类具有明确“元素坐标”的可视化用SVG渲染。SVG的DOM节点天然可以绑定事件悬停到某个数组元素上时能显示详细状态信息这个交互在SVG里实现起来非常优雅。粒子群、模拟退火这类有大量连续运动粒子的场景用Canvas渲染。粒子数量多的时候超过200个SVG的DOM节点开销会导致掉帧Canvas的位图绘制反而稳定。提示如果你也遇到“动画卡顿”问题先别急着优化算法看看是不是渲染选型搞错了。像粒子群这类需要高帧率连续渲染的场景直接用Canvas像排序算法这种“状态切换型”动画用SVG足够反而能白嫖它的DOM事件绑定能力。4.4 交互设计播放、暂停、步进、调速、跳帧编辑器端的交互必须兼顾“看整体”和“抠细节”两种需求。播放/暂停最基础的不赘述。步进每次前进一个快照。这是最有用的教学功能老师可以一步步展示算法执行过程。速度控制我提供了0.5x、1x、2x、4x四档速度。播放器不是简单地把动画时长减半而是同时调整快照间的补间插值精度——高速下减少中间帧低速下增加中间帧保证不跳步。跳帧Scrubbing这是后期加的功能。播放器底部有一个时间轴本质是快照序号滑条拖动它可以直接跳到任意一个算法状态。在调试算法实现或者做演示回放时非常好用。4.5 Web Worker隔离算法执行环境算法代码不是完全可信的用户可能会在算法代码块里写一个死循环或者一个无限递归。如果放在主线程执行整个编辑器都会卡死这是绝对不能接受的。所以我把所有算法代码的编译和执行都放在Web Worker里主线程把代码文本通过postMessage发送给Worker。Worker内部用new Function包装传入代码并注入一个受限的snapshot函数。Worker同步执行算法产生快照序列再把快照序列一次性传回主线程。这里有个小细节Worker里没有postMessage的同步等待机制所以算法执行过程中不能边跑边发消息只能等执行完了一次性传回。对于超大输入比如排序算法跑1万个元素快照序列可能会非常大达到几十MB传回主线程时会卡住几秒钟。我的优化方案是在Worker内部先对快照序列做一次降采样。只在算法执行过程中每N步记录一条快照并同时保留每条快照的“事件类型”信息。排序算法可以放心降采样因为相邻快照之间大部分元素位置没变动画播放器会自动补间过渡。5. 实测运行效果拿三个典型算法当参照理论讲再多不如直接看实测。我拿排序、字符串匹配、数值优化三类里最典型的算法跑了完整流程说说效果和细节。5.1 快速排序递归栈可视化是最亮眼的部分快速排序的可视化有一个天然优势它的递归结构本身就能画成一张树形图。我在主数组上方叠加了一个递归栈面板每一层递归对应树上的一个节点节点内的半透明矩形表示当前partition操作处理的区间。实测下来观众能很清楚看到每一层partition把区间缩小成两部分。基准元素在递归树的每一层都有一个对应的放置位置。递归深度一目了然最坏情况数组已有序会画出极度倾斜的递归树这比任何文字描述都直观。5.2 KMP算法next数组构建过程的特殊处理KMP算法的动画可视化难点在于next数组的构建是一个独立的“自动机”过程它和主串匹配过程是分开的但教学中必须把这两者放在同一个视野里。我的实现里是这样处理的动画首先完整播放next数组的构建过程用模式串自身做匹配等next数组表填充完成后主串匹配动画才会开始。而且在主串匹配时每当发生“失配跳转”动画会在主串和模式串的错配字符之间显示一个大的红色交叉号然后画一条弧线将模式串位置指向next[j]位置并短暂地高亮模式串中“跳过的部分”。实测中我发现真正让观众看懂KMP的往往不是那一次弧线跳转而是next数组构建过程里“相等前缀延续”的动画。所以我在构建next数组时对于每个相等的前后缀匹配会用一个同色系的高亮条覆盖在前缀和后缀上观众能明显看到“这段和那段是一样的”。这个视觉信号比任何公式都更容易被接受。5.3 粒子群算法从一团乱麻到聚拢粒子群的可视化是视觉上最“爽”的。初始时50个粒子随机散布在二维平面上颜色是斑斓的杂色。随着迭代进行粒子逐渐向某个区域聚拢颜色也开始趋同。最终粒子群像被磁铁吸引一样集中到最优解附近。动画实现的细节在于粒子每次移动的距离很小单纯用requestAnimationFrame逐帧绘制粒子位置时需要把“一次迭代”这个逻辑单位转换成“一帧移动四分之一距离”的视觉单位。我在粒子群算法的快照序列中记录的粒度是“一轮迭代结束时的所有粒子位置”播放器在渲染时会对相邻两轮迭代的粒子坐标做线性插值生成平滑的运动轨迹。6. 项目里常见的坑和解决思路这个项目从开发到跑通踩过不少坑。挑几个有代表性的说说希望能帮你避开。6.1 快照中包含大数组时的序列化性能问题每个快照里都包含一个完整的数组切片arr.slice()。排序算法跑200个元素时这个数组不过200个数字序列化几乎无感。但如果你让粒子群算法跑5000轮迭代每次迭代都记录所有50个粒子的坐标、速度、适应度那快照总量就会膨胀到难以处理。我的解决办法是给快照记录器加了一个“分片存储”的能力每个快照有一个prevRef指向上一份快照。如果当前快照与上一个快照的数据变化量小于阈值比如只有3个粒子的位置变了就不存完整数组只存“差异部分”。播放时动画播放器根据差异重建完整状态。这个压缩方案让快照序列的体积平均减少了85%左右。6.2 算法代码里用了ES6新特性导致Worker加载失败内置算法代码我用了很多ES6语法解构赋值、箭头函数、模板字符串但在Web Worker里new Function创建的函数作用域中某些语法需要额外的解析器支持。如果直接用浏览器原生的new Function碰到ES2020以上的可选链操作符?.可能直接报错。我的处理方式是在Worker内部先引入一个轻量级的JavaScript解析/转译器如acorn把用户输入的代码先转换成ES5再丢进new Function执行。虽然损失了一点点执行性能但换来了兼容性稳定。6.3 动画播放器和编辑器滚动容器的坐标同步这是个典型的“看起来简单、做起来烦”的问题。动画画布如果放在代码块下方随着编辑器滚动画布的位置会变化。如果画布内部有拖拽交互比如拖拽时间轴滑条拖拽过程中的鼠标坐标是相对于视口的而画布元素本身也在滚动坐标就会错乱。解决方案是画布组件在监听拖拽事件时始终使用getBoundingClientRect()实时获取画布偏移量而不是在初始化时缓存一次。6.4 排序算法的稳定性在动画中如何体现这是个很多人没注意到的问题。同样是交换两个相等元素的位置稳定的排序算法如归并、冒泡不会改变相同值元素的相对顺序而不稳定的算法如快速排序可能会改变。如果用数值高度表示元素大小当两个元素值相等时它们交换与否在视觉上完全看不出来。我在动画里给数组中的每个元素分配了一个唯一的“实例ID”元素的颜色深浅由这个ID决定。这样一来相等值的元素也会因ID不同而有细微的颜色差异观众就能看到稳定排序中相同值元素“不会交叉”的效果也能看到不稳定排序中相同值元素“交叉换位”的场景。这个细节让动画的教学价值提升了一个档次。6.5 动画播放器的时间轴放大功能对于归并排序这种有大量递归步骤的算法快照数量通常在几十到几百之间。直接查看时每一个快照在时间轴上占的位置太小根本看不清。我加了一个时间轴缩放功能——按住Shift键滚动鼠标滚轮时时间轴可以放大到显示单个快照的粒度这样老师可以精确地指向某个具体状态然后按步进键给观众讲解。7. 后续扩展方向项目目前已经能覆盖大部分算法教学场景但还有一些值得做的方向如果你感兴趣可以继续扩展。一是支持用户自定义动画主题。有的人喜欢深色背景的代码块有的人喜欢浅色。我的可视化框架目前是浅色主题后续希望做成可配置的。二是录制动画为GIF或WebM视频。Markdown编辑器里生成动画已经很好了但如果你想把它嵌入到PPT或者分享给不能运行编辑器的人能直接导出成视频会方便很多。三是算法对比模式。把两种排序算法部署到同一份随机数组上并排播放动画同时显示各自的比较次数和交换次数。这个功能一旦做出来排序算法“时间复杂度和常数系数”的关系就不需要老师反复口述了一目了然。四是把快照序列嵌入生成式博客。可以做一个导出功能把Markdown里的算法块和动画快照打包成一个静态HTML文件别人打开这个文件就能看到完整的算法演示。这样你的技术博客就不再是一张死图的天下而是真正可交互的。我自己的下一步打算是先把导出功能做了。因为这段时间分享给朋友看所有人第一句话都是“这东西怎么导出成文件发给我”。他们的需求很直接——不是每个人都会搭一个Markdown编辑器环境但每个人都能打开一个HTML文件。这个项目让我自己最大的收获是当你把一个抽象的过程变成可视化的动态画面时你对它的理解会比以前深刻得多。很多算法我在做可视化之前以为自己已经懂了但为了设计动画节奏、为了决定哪些状态值得记录我必须把它们的每一步执行都像慢放一样在脑子里过一遍。这时候才发现有些一直以为懂了的细节其实根本没懂。