PR 留 review 前先看清楚
GitHub 的 diff 已經很好,但有時你只想看「實質變更」,把 formatter 雜訊濾掉。把兩個版本貼進來、打開「忽略空白」— 表面 reformat 全部消失,只留下邏輯編輯。
比對兩段文字或程式碼,逐行 + 逐字 highlight。並排或統一視圖、忽略空白、忽略大小寫 — 完全在你的瀏覽器內運算。
不會。整個工具就是這個分頁裡的 JavaScript。Diff 演算法(LCS,longest common subsequence)在你的 CPU 上跑,結果直接渲染到 DOM。打開 DevTools → Network 即可驗證:比對過程不會發任何請求。可以放心貼上內部程式碼、客戶資料、合約草稿等任何不該被伺服器記錄的內容。
先把兩邊輸入按行切開,跑 LCS(longest common subsequence)演算法。兩邊都有的行標記為「相等」;不相等的行會配對成「change」列(刪除緊接著新增就配對)。對每個配對的 change 列,我們在這行的字詞上(以空白切分)再跑第二次 LCS,所以只有真正被編輯的字詞會變紅/綠 — 不是整行變色。
為開發者、寫作者,以及任何想看「到底改了什麼」的人打造的乾淨快速 diff 工具 — 沒有彈出廣告,也沒有第三方追蹤。
一鍵切換並排(IDE 風格的兩欄)與統一(單欄附 +/− 標記)。兩種視圖都會顯示行號,並逐字 highlight 變更部分。
當兩行有差異,我們會在這對行上跑第二次逐字 diff — 只有真正不同的部分會被標色,而不是整行變色。在 200 字的長行裡找一個錯字也很輕鬆。
切換空白與大小寫敏感度,過濾掉表面上的差異(重新縮排、大小寫調整),只專注在真正的編輯。
兩段文字都留在你的瀏覽器分頁。Diff 演算法在本地的 JavaScript 執行。可在 DevTools → Network 驗證:輸入時零網路請求。
一眼看到新增、刪除、修改了幾行。一鍵把 diff 複製到剪貼簿,直接貼進 code review 或 commit message。
頁面載入後所有運算都在本地 — 飛機上、企業防火牆後、甚至沒網路都能用。處理機密 code review 特別有用。
演算法本身比 web 還老 — 1965 年的 LCS,加上 1986 年 Eugene Myers 的優化。
兩邊輸入都用 \n(或 \r\n)切開。每行就是一個 token。我們比對 token,而不是逐字 — 因為真實世界裡多數編輯都是新增、刪除或修改整行。
Longest Common Subsequence 是兩邊以相同順序出現的最大行集合。我們從右下角開始填 DP 表,每格存「從這個位置到結尾的 LCS 長度」。時間與記憶體都是 O(m × n)。
從表格的左上角往前走:若兩邊當前行相同,輸出「相等」;否則往右或往下選能保住 LCS 長度的方向,輸出「刪除」或「新增」。結果是一串能把 Original 變成 Modified 的操作序列。
當刪除緊接著新增,我們把它們配對成「change」列。為了只 highlight 行內真正不同的部分,我們以空白切分這對行的字詞,再跑一次同樣的 LCS。
你會在哪些情境下需要 diff checker?
GitHub 的 diff 已經很好,但有時你只想看「實質變更」,把 formatter 雜訊濾掉。把兩個版本貼進來、打開「忽略空白」— 表面 reformat 全部消失,只留下邏輯編輯。
法務或 ops 常需要知道合約 v1 跟 v2 改了什麼。兩份貼上,馬上得到帶逐字 highlight 的彩色 diff — 不用 Word、不用追蹤修訂、不會把機密條款上傳到別人的伺服器。
用 sed/awk/Python regex 改過設定檔?把原始檔和結果貼進來,確認腳本只動了預期的部分。逐字 highlight 能抓到肉眼掃過會漏的零星修改。
翻譯對照(原文 vs 譯文,或同一原文的兩種譯本)— 逐字 diff 讓「漏字、重複片語、標點翻轉」這類校稿時容易漏掉的問題一目了然。
你比對的文字通常是私密的:內部 repo 的程式碼、合約草稿、客戶資料匯出、未發布的產品文案。把這些貼到別人的伺服器,等於留下你無法控制的紀錄。iKit 的 diff checker 就是已載入瀏覽器分頁的 JavaScript — 比對在你的 CPU 上執行,完全沒經過網路。
來自 iKit 部落格的深入教學與工具比較。
Pretty-print, validate, and structurally diff messy JSON — when each one is the right tool.
Compare the best Markdown editors of 2026; pair with the diff tool for tracking documentation changes.
不會。整個工具就是這個分頁裡的 JavaScript。Diff 演算法(LCS,longest common subsequence)在你的 CPU 上跑,結果直接渲染到 DOM。打開 DevTools → Network 即可驗證:比對過程不會發任何請求。可以放心貼上內部程式碼、客戶資料、合約草稿等任何不該被伺服器記錄的內容。
先把兩邊輸入按行切開,跑 LCS(longest common subsequence)演算法。兩邊都有的行標記為「相等」;不相等的行會配對成「change」列(刪除緊接著新增就配對)。對每個配對的 change 列,我們在這行的字詞上(以空白切分)再跑第二次 LCS,所以只有真正被編輯的字詞會變紅/綠 — 不是整行變色。
並排視圖把兩段文字左右並列,搭配對應的行號 — 比較像 IDE(VS Code、JetBrains)的 diff。統一視圖只顯示一欄,行首加 +/− 前綴 — 比較像 `git diff` 的輸出。挑你工作流順手的那個用,兩者顯示的是同一份資料。
重新格式化程式碼(跑 Prettier、切換 tab / space、統一行尾)會帶來大量視覺雜訊,把真正的修改埋掉。打開「忽略空白」會在比對前把連續空白縮成一個空白並 trim 兩端 — 你看到的就只剩有意義的編輯,不會被表面差異干擾。
LCS 演算法的記憶體是 O(m × n),m、n 是兩邊各自的行數。iKit 把上限設在約 400 萬格(≈16 MB),足夠應付數千行 vs 數千行的比對。更大的 diff(整個資料庫 dump、整檔 log)請用 CLI 工具如 `diff` 或 `git diff --no-index` — 它們用更聰明的演算法(Myers diff),可以處理數百萬行。