★ FEATURED ARTICLE 简介一个基于Web技术实现的简易Git diff对比工具面向需要快速查看文件差异的开发者以及正在学习Git原理和前端交互的初学者。它借助浏览器界面模拟Git diff的变更展示效果用户无需在命令行中执行Git命令下载后双击即可在本地运行轻量且零依赖。压缩包共四个文件包括一个HTML、两个JavaScript和一个CSS文件HTML负责页面骨架CSS完成界面配色与布局JavaScript承担diff数据解析、差异高亮、代码折叠等核心交互逻辑整体仅三十一KB体积很小。目前已有两百零三人学习或浏览适合前端学习者通过源码了解第三方diff渲染库的基本用法也能帮助Git入门者更直观地理解两种文本版本之间的差异。无论是快速比对配置文件变更还是查看代码片段改动这个工具都能提供一目了然的可视化反馈。通过阅读代码还能积累纯前端工具从结构搭建到交互实现的完整思路是一个小巧但可扩展性不错的练手示例如需二次开发可以将其中的差异渲染逻辑迁移到自己的项目中快速打造更贴合个人需求的对比工具。1. 怎么用 Web 做一个能看的 diff 页面而不是只能跑的 diff 脚本如果你天天对着命令行敲git diff大概率想过能不能把这个差异结果搬到浏览器里让同事、产品、测试不用开终端也能看懂这就是“一个 Web 实现的非常简易的类似 git diff 的页面”在做的事。它不需要你引入一套完整的 Git 可视化平台更不需要动 Git 仓库的底层对象只要把两段文本拿来算出差异再用 Web 页面展示出来就够了。这类页面最常见的场景是文本对比工具、配置文件的版本差异查看、两个接口返回报文的比对以及在线判题系统里展示用户输出和标准答案的差别。难点不在算而在“算得快”和“展示得清楚”。纯文本 diff 的算法本身并不复杂但一旦文本到了几千行、单行内容很长或者包含中文、emoji、混杂换行符计算和渲染都会出问题。这篇文章会从算法选型、Web Worker 分片、虚拟滚动渲染、踩坑记录到验证方法给你一条能照着落地的完整路径。适合动手做的人有两类一类是 Web 前端开发者想在项目里嵌一个轻量对比组件另一类是后端工程师想在企业级 Web 开发里快速给内部工具加一个文件比对页面。不依赖任何重型框架原生 JavaScript 就能跑通React、Vue 工程里也能直接搬。2. diff 算法选型LCS、Myers 还是直接拿别人封装好的库2.1 先搞清楚 diff 的核心在算什么diff 的核心不是“两段文字哪里不一样”而是“怎么把差异描述成最小的编辑操作序列”。拿两段文字逐字符对比你看一眼就知道哪里改了但计算机得在“删除、插入、替换”三种操作里找一条最短路径。这个问题的标准解是 LCSLongest Common Subsequence最长公共子序列动态规划就能做把两段文本按行拆成两个数组每行是一个“元素”算出两个数组的最长公共子序列属于公共子序列的行是“未变”只在左边出现的是“删除”只在右边出现的是“新增”。LCS 的实现非常直观但成本是 O(nm) 的时间和空间。两段各 5000 行的文本nm 就是 2500 万JavaScript 里跑一遍还能接受再大就要卡了。很多现成的 diff 库其实用的并不是标准 LCS而是 Myers diff 算法。Myers 算法的核心思路是寻找编辑脚本的最短路径它把“删除 插入”的次数作为路径长度用贪心的方式从左上角往右下角搜。通常来说LCS 适合“求最长公共子序列本身”的场景Myers 适合“求最小编辑脚本”的场景——git diff 使用的就是类似 Myers 的思路。如果你只是做一个“非常简易”的页面不要一上来就自己撸算法。JavaScript 生态里有成熟的 diff 库例如diffjsdiff和fast-diff。前者实现完整支持字符级、单词级、行级、JSON 级多种 diff后者基于 Myers 思想只返回“相同/不同”两种标记单次 diff 速度极快。我的建议是行级对比用diff库的diffLines字符级对比用fast-diff生产项目别自己写 LCS——这里的坑比你想的多。2.2 最小可运行的自实现行级 diff虽然不建议生产环境手写但你最好自己实现一次理解原理之后调参和排错都会顺手很多。下面这段代码是“两段文本按行对比”的最小实现采用 LCS 动态规划加回溯function diffLines(oldText, newText) { const oldLines oldText.split(\n); const newLines newText.split(\n); const n oldLines.length; const m newLines.length; // 构建 LCS 长度矩阵dp[i][j] 表示 oldLines 前 i 行与 newLines 前 j 行的 LCS 长度 const dp Array.from({ length: n 1 }, () new Array(m 1).fill(0)); for (let i 1; i n; i) { for (let j 1; j m; j) { if (oldLines[i - 1] newLines[j - 1]) { dp[i][j] dp[i - 1][j - 1] 1; } else { dp[i][j] Math.max(dp[i - 1][j], dp[i][j - 1]); } } } // 回溯生成操作序列common | delete | add const result []; let i n, j m; while (i 0 j 0) { if (oldLines[i - 1] newLines[j - 1]) { result.unshift({ type: common, line: oldLines[i - 1] }); i--; j--; } else if (dp[i - 1][j] dp[i][j - 1]) { result.unshift({ type: delete, line: oldLines[i - 1] }); i--; } else { result.unshift({ type: add, line: newLines[j - 1] }); j--; } } while (i 0) { result.unshift({ type: delete, line: oldLines[i - 1] }); i--; } while (j 0) { result.unshift({ type: add, line: newLines[j - 1] }); j--; } return result; }这段代码的逻辑分两段先正向填充 dp 矩阵再反向回溯。oldLines[i - 1] newLines[j - 1]是“行内容完全相等”的判断这也是整个 diff 的基准粒度——按行对比时只要这一行内容完全相同就算“未变”。如果你想做字符级对比就得把这个判断拆到字符维度复杂度会上升很多。参数说明oldText和newText是完整文本字符串函数内部按\n切分最后返回的result是带type标记的行数组。这个实现对几百行的文本完全够用但你要清楚它的边界空间复杂度 O(n*m)文本一大内存直接撑爆。这就是我接下来要说为什么生产环境尽量用成熟库的原因。2.3 选库的边界条件和参数调优当你用 npm 安装diff库并调用diffLines(oldStr, newStr)时默认行为是逐行对比返回一个对象数组每个对象有value、added、removed、count字段。比较关键的参数有这几个newlineIsToken传入true时把换行符当作独立的 token 处理适合处理行尾差异敏感的配置文件ignoreWhitespace忽略行内空白差异适合对比代码格式化前后的文本context部分 diff 库支持控制在统一 diff 格式里展示多少行上下文默认是全部展示但你可以设置成 3让输出更接近git diff的默认效果。如果你选了fast-diff它的使用方式更简单diff(oldStr, newStr)直接返回一个数组每个元素是[操作类型, 文本片段]操作类型0表示相同、1表示新增、-1表示删除。这个库对超大文本更友好因为它的实现基于 Myers 且做了内存优化但代价是你拿不到“统一 diff 格式”那种结构化的行级信息。所以我的习惯是最终展示效果偏 Git 风格就用diff库偏“纯高亮差异”就用fast-diff。3. Web 架构设计为什么会卡顿以及 Worker 线程的正确用法3.1 为什么不用主线程直接算 diffWeb 页面的主线程要负责渲染、事件响应、布局计算。如果你在主线程里跑一个 O(n*m) 的 diff 算法几百行的文本还好一旦文本上到几千行浏览器会直接卡住——滚动没反应输入框打不了字用户会以为页面死了。解决思路是开 Web Worker把 diff 计算放进独立线程算完再把结果通过消息传递回主线程。但请注意Web Worker 不是万能的。首先Worker 里不能操作 DOM其次Worker 和主线程之间传消息有序列化和拷贝成本。如果你把一个几十万字符的文本传给 Worker再用 Worker 把整个 diff 结果传回来这中间的postMessage耗时可能比 diff 本身还长。常见的做法是“分片传、增量算”不是把整个结果一次性传回而是在 Worker 内部维护状态计算完一个 diff 块就通过回调传一块。不过对于简易版工具没必要做那么重把完整文本一次性传给 Worker 就够了。3.2 最小可运行的 Worker 通信代码下面是一份精简的 Worker 实现。主线程负责接收文件内容或粘贴的文本发送给 WorkerWorker 计算完把结果返回。// diff.worker.js self.onmessage function (e) { const { oldText, newText, diffType } e.data; // 这里用 diff 库的 diffLines 做行级对比 importScripts(https://unpkg.com/diff/dist/diff.min.js); const parts Diff.diffLines(oldText, newText); // 把结果组装成统一的展示结构 const rows []; parts.forEach((part) { const type part.added ? add : part.removed ? delete : common; const lines part.value.split(\n); lines.forEach((line) { rows.push({ type, line }); }); }); self.postMessage(rows); };主线程这边的调用方式const worker new Worker(./diff.worker.js); worker.onmessage function (e) { const rows e.data; renderDiff(rows); }; worker.onerror function (e) { console.error(diff worker error:, e.message); }; function startDiff(oldText, newText) { worker.postMessage({ oldText, newText, diffType: line }); }这段代码有两个关键点。第一importScripts是 Worker 内部加载外部脚本的方式只能加载同源或允许跨域的脚本生产环境里你应该把 diff 库打包进 Worker而不是依赖 CDN——不然离线环境和内网部署会直接挂掉。第二postMessage传递的是结构化克隆数据rows 数组里的普通对象、字符串都是可以安全传递的但如果你哪天想把Map或Set传过去结构化克隆支持有限先转成数组再传。3.3 数据量再大一层分块预处理与降档策略如果你的工具要支持“上万行文本对比”单靠 Worker 还不够。我常用的策略是先做一次快速预判对超长文本走“哈希降档”路线。做法很简单把每行文本做一次哈希比如hash line.length line.charCodeAt(0)叠加然后对哈希数组做 diff。这样能快速定位差异区域再对差异区域的行做全文本对比。代价是有哈希碰撞导致误判的风险但对简易工具足够用。另一个思路是“只显示前 N 处差异”这在做配置对比时特别实用。比如只返回两个文本的前 50 处不同渲染时不会卡用户也不需要一次性看完全部差异。你可以在 Worker 里维护一个计数器达到阈值就终止计算然后postMessage通知主线程“还有更多差异已截断”。这个方案说起来简单但要注意终止后的状态清理——Worker 是长驻的计算到一半你不退出 PostMessage 的话下次启动任务会串数据所以每次新任务进来第一件事就是重置状态。4. 渲染层实现从 rows 数组到可读的 diff 视图4.1 最基础的渲染结构左右分栏还是统一块状diff 结果拿到之后怎么展示是另一个学问。Git 默认的 unified diff 格式是“上下文 增删行混排”但 Web 页面里用户更常看的是左右分栏左边是旧文本右边是新文本中间用颜色标出增删。左右分栏的渲染逻辑比较麻烦因为两边的行号不是一一对应的你得让“新增行”在右边独占一行“删除行”在左边独占一行“未变行”左右对齐在同一行。实现方式很简单把 diff 结果 rows 数组转成 grid 表格行每一行固定包括“旧行号、旧内容、新行号、新内容”四个字段。function renderDiff(rows) { const container document.getElementById(diff-view); container.innerHTML ; const table document.createElement(table); table.className diff-table; let oldLineNo 1; let newLineNo 1; rows.forEach((row) { const tr document.createElement(tr); if (row.type common) { tr.innerHTML td classline-no${oldLineNo}/td td classcontent${escapeHtml(row.line)}/td td classline-no${newLineNo}/td td classcontent${escapeHtml(row.line)}/td; oldLineNo; newLineNo; } else if (row.type delete) { tr.innerHTML td classline-no${oldLineNo}/td td classcontent delete${escapeHtml(row.line)}/td td classline-no/td td classcontent/td; oldLineNo; } else if (row.type add) { tr.innerHTML td classline-no/td td classcontent/td td classline-no${newLineNo}/td td classcontent add${escapeHtml(row.line)}/td; newLineNo; } table.appendChild(tr); }); container.appendChild(table); }逻辑说明oldLineNo和newLineNo是两套独立计数器遇到common同时递增遇到delete只递增旧行号遇到add只递增新行号。这样左右两列的行号才能和原始文件对上。escapeHtml是必须的——diff 结果里如果包含script或img onerror不转义直接插 innerHTML 会导致 XSS 漏洞。这一点在 Web 安全上尤其重要拿真实文件路径或者用户上传内容来对比时一定要默认所有内容都是不可信的。表格渲染的一个坑是性能如果 diff 结果是 20000 行你一次性创建 20000 个tr节点插入 DOM浏览器照样卡死。所以下一步要做虚拟滚动。4.2 虚拟滚动只渲染可视区域内的 diff 行虚拟滚动的思路是容器高度固定监听滚动事件计算当前可视区域对应的行索引范围只渲染这个范围内的 DOM 节点。实现关键在“行高估算”和“滚动位置换算”。const ROW_HEIGHT 24; // 每行高度固定单位 px const container document.getElementById(diff-scroll-container); const spacer document.getElementById(spacer); // 撑开滚动条的空 div function updateVisibleRows() { const scrollTop container.scrollTop; const viewportHeight container.clientHeight; const startIndex Math.floor(scrollTop / ROW_HEIGHT) - 5; // 向上多渲染 5 行缓冲 const endIndex Math.ceil((scrollTop viewportHeight) / ROW_HEIGHT) 5; const visibleRows rows.slice(Math.max(0, startIndex), Math.min(rows.length, endIndex)); const content document.getElementById(diff-content); content.style.transform translateY(${startIndex * ROW_HEIGHT}px); content.innerHTML ; visibleRows.forEach((row) { content.appendChild(buildRowElement(row, startIndex)); }); spacer.style.height rows.length * ROW_HEIGHT px; }这里的核心技巧是把“可视区渲染”和“滚动条模拟”分开。spacer负责把滚动条撑到全长content用transform: translateY平移这样就不需要频繁操作每个行的top定位。startIndex和endIndex各加 5 行缓冲是防止快速滚动时出现白屏闪烁——滚动事件触发频率很高如果渲染范围刚好卡在视口边缘很容易露底。这个缓冲经验值是 3 到 10 行取 5 是一个比较稳的中间值。4.3 语法高亮和颜色方案让差异一眼可读颜色方案上别用太花哨的配色。我一般用 Git 风格的三色删除行背景#ffd7d7浅红、新增行背景#cdffd8浅绿、未变行背景透明。文字颜色保持深灰行号颜色淡一些视觉层次就出来了。如果你要对比的是代码文件可以对common行做语法高亮——但注意高亮必须在虚拟滚动的行渲染里单独做不能一次性对整个 rows 做高亮否则又是性能灾难。高亮库的选择如果项目里已经用了 Prism 或 highlight.js直接用现有方案如果没有可以搜一下轻量正则高亮的方案。最省事的做法是不做代码高亮只保留 diff 的颜色区分因为绝大多数场景下用户关心的是“哪里变了”而非“这段代码的语法结构”。5. 避坑记录中文、emoji、超长单行和换行符的四类典型问题5.1 换行符导致整行全红明明内容没有变化现象两个文件在 Linux 和 Windows 分别编辑过对比时每一行都被标记为“删除 新增”diff 结果惨不忍睹。原因\r\n和\n在字符串比较中不等同。按行切分时旧文本的行尾可能带着\r新文本没有导致每一行都不相等。解决在切分之前统一做一次规整oldText oldText.replace(/\r\n/g, \n)或者按行切分后对每行做line.replace(/\r$/, )。这个处理要放在 diff 计算之前而不是渲染之前否则 Worker 里算出来就已经是错误结果了。5.2 emoji 和组合字符导致字符级 diff 位置错乱现象一段文本里包含“”这样的家庭 emoji或者带音调的拼音字符字符级 diff 高亮的位置看起来是劈开的、半截符号。原因JavaScript 的字符串按 UTF-16 编码一个 emoji 可能占两个 code unit组合 emoji 甚至占四个。你用split()切割字符串时会把一个完整的 emoji 切成两个半截字符diff库默认按 code unit 处理自然会把 emoji 劈开。解决如果是行级 diff这个问题不会出现如果是字符级 diff先做一次 Unicode 感知的切分。用Array.from(str)或者Intl.Segmenter按“用户感知的字符”切分再把切分结果传给 diff 库。Intl.Segmenter是现代浏览器提供的分词 API对 emoji 的处理比Array.from更准确但它返回的是一个 iterator需要转成数组再使用。5.3 超长单行文本让虚拟滚动彻底失效现象对比两份日志文件时有一行特别长比如 5 万字符导致这一行渲染出来的高度远超预设ROW_HEIGHT滚动条位置错乱、内容重叠。原因虚拟滚动的前提是“固定行高”。单行内容过长自动换行后行高不再是 24px而是几十甚至上百 pxMath.floor(scrollTop / ROW_HEIGHT)的换算就全错了。解决给 content 单元格加上white-space: pre强制不换行配合横向滚动条处理超长行。或者反过来把超长行按宽 - 度或固定长度切成多段显示但要注意这会破坏 diff 的行对齐。我一般倾向强制不换行因为超长行在 diff 场景里是特例用户可以用横向滚动去看完整内容。5.4 大文件内存占用高页面直接崩溃现象对比两个 10 万行的文件页面卡顿移动端直接白屏。原因diff 库计算出的结果全部存在 rows 数组里渲染时又复制到 DOM内存占用轻松超过几百 MB。解决第一步在 Worker 里就算完就结束别把完整 rows 再传回主线程改成传一个轻量的摘要第二步如果场景允许只渲染差异区域的前 N 条提供“加载更多”按钮第三步确认没有循环引用或重复引用rows 数组里不要保留原始全文只要每一行的 type 和 line 即可。这三个步骤都做到10 万行文本的内存占用能控制在 100 MB 以内。5.5importScripts加载 CDN 失败Worker 静默失效现象部署到内网环境或离线环境diff 计算没反应控制台也不报错。原因importScripts加载外部 CDN 失败时Worker 的 onerror 不会稳定触发或者你根本没写 onerror 处理。内网环境访问不到公网 CDN 是最常见的情况。解决构建时直接把 diff 库打包进 Worker。如果你用的是 Vite可以通过?worker后缀导入让构建工具处理打包如果没用构建工具就把 diff 库下载到本地用相对路径importScripts(./diff.min.js)。顺手在worker.onerror里加一个弹窗或日志提示方便排查。6. 进阶技巧怎么验证你的页面真的和 git diff 一致6.1 用 git diff 生成黄金样例做对拍验证做完一个 diff 页面最怕的不是功能没有而是“部分结果和 git diff 不一致”。验证方法很简单准备一组文本样例比如 20 个不同大小的场景用git diff --no-index old.txt new.txt生成期望结果再把同样的文本丢进你的页面对比输出是否一致。git diff --no-index --unified0 old.txt new.txt expected.diff注意--unified0表示不输出上下文行这样生成的是最精简的差异结果。你的页面渲染结果如果想对齐这个格式也需要在展示时支持“只看增删行、包含行号”的模式。对拍时可以写一个 Node 脚本读取 expected.diff 和你页面输出的 JSON逐行对比每一行的操作类型和内容。6.2 性能基准测试的常用做法性能测试不要只看“跑完没跑完”要分开测两个指标计算时间和首屏渲染时间。计算时间在 Worker 里用performance.now()打点首屏渲染时间在requestAnimationFrame之后记录时间戳。常见的目标1000 行文本 diff 计算时间不超过 50ms渲染时间不超过 100ms10000 行文本 diff 计算时间不超过 500ms配合虚拟滚动渲染不卡顿。如果计算时间超标优先检查是不是 LCS 矩阵太大如果渲染时间超标优先检查是不是 DOM 节点数过多。这两个问题的优化方向完全不同别混在一起调。6.3 再进一步支持粘贴文件、URL 参数和 JSON 对比我见过很多 diff 页面上线之后被问的第一句话就是“能不能直接拖文件进来”。这个功能实现成本很低监听 drag 事件用FileReader把文件内容读成字符串塞进现有的 diff 流程就行。URL 参数对比也值得加——把两个文本的 URL 或 base64 编码放进 query 参数方便分享给同事。如果你要对比 JSON 结构不建议直接对字符串做 diff。先把 JSON 解析成对象再按 key 排序、序列化成统一格式这样能避免“只是 key 顺序不一样”导致的假差异。这个序列化逻辑要放在 Worker 里做避免大数据量 JSON 在主线程卡顿。我自己的习惯是每次新加一种 diff 场景就顺手把这个场景的样例文本和期望结果存成一个cases.json下次改完代码直接跑一遍回归。这个动作坚持下来比什么自动化测试工具都管用。做这个简易 diff 页面最大的收获不是算法本身而是你会发现“对比”这个动作藏了一堆细节——行尾、编码、字符宽度、渲染性能——每一个都值得认真对待。希望这些踩坑经验能帮你少走一段弯路。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
