瀏覽器版的差異比對工具，就是檔案層級版本，回答的其實是和大家問 Google 地圖不同時間點時一樣的「比較兩個時間點」問題：把原始文字貼在左邊，把新版本貼在右邊，然後在兩個方塊下方閱讀逐行的差異結果。當你想知道另一個城市現在是幾點、早上 8 點和晚上 6 點的交通狀況差多少，或是某個地點在星期日 14:00 是否營業時，Google 地圖顯然是最直覺的工具。這些問題本質上都是「比較兩個數值，告訴我差在哪裡」。當問題從地理座標與時鐘，換成一份文字文件、原始碼檔案、JSON 資料，或設定檔時，這項任務的結構其實一模一樣：左邊的輸入、右邊的輸入，以及兩者之間的差異。一個為此目的打造的免費線上差異比對工具，會標示出每一行新增、刪除與未變動的內容，讓你可以快速瀏覽一份長檔案，並立刻找出真正重要的修改。
大家在 Google 地圖上說「不同時間」，實際上是指什麼
在 Google 地圖上搜尋不同時間的需求，通常可以歸納成三個實際的類別，而每一種都能乾淨地對應到「比較兩個時間點」的任務上。第一種是時區查詢：「柏林中午的時候，東京是幾點」——這是直接比較兩個時鐘。第二種是歷史與預測交通狀況：「星期二早上 7 點 30 分，和星期五下午 5 點 00 分，這條路線看起來有什麼不一樣」——這是比較同一條道路網路的兩張快照。第三種是營業時間與季節性時程：「這座博物館在星期日 14:00 有沒有開」——這是把一個時間點，拿去和一個預期範圍做比較。
這些情境有一個共通點：使用者手上已經有兩個數值（一個「之前」與一個「之後」，或是一個「這裡」與一個「那裡」），想知道其中的差異。介面會改變——一張地圖，還是兩個文字方塊——但底層的操作是一樣的：把兩個輸入內容對齊、找出哪些是共同的，再回報哪些不是。
為什麼比較檔案是同一個概念
一旦問題從地圖轉移到文字上，「不同時間」這個框架反而更貼切。昨天的文件版本，與今天的文件版本，就是時間軸上的兩個時間點，而「改變了什麼」正是與「兩個地方現在幾點」完全相同性質的問題。為這種比較而打造的工具，在軟體領域已經存在了好幾十年：Unix 的 diff 工具、Git 的 commit 檢視畫面，以及 GitHub 與 GitLab 中的並排比較功能，對程式碼做的都是同一件事，而且它們全都使用最長共同子序列（Longest Common Subsequence，LCS）演算法，如 documented on Wikipedia 所記載。
一個線上的 diff checker，會把同樣的 LCS 方法，套用到你貼進瀏覽器的兩段文字輸入上。原始版本放進左邊的方塊，修改後的版本放進右邊的方塊，這個工具就會依序計算出兩者之間最長的共同行序列。位於這個共同骨幹內的每一行，都會被標記為未變動；骨幹之外的每一行，則會被標記為新增（開頭加上 +）或刪除（開頭加上 -）。這就是「我要怎麼檢查我的檔案不同時間點之間的差異」這個問題，實際可行的答案，而且它適用於任何以「行」作為有意義變動單位的純文字。
如何用 Diff Checker 比較一份檔案的兩個版本
- 在瀏覽器裡開啟 Diff Checker。
- 把原始文字貼進左邊的「Original」方塊。
- 把新版本貼進右邊的「Changed」方塊。
- 閱讀下方逐行呈現的結果：標記 + 的行代表新增，標記 - 的行代表刪除，摘要則會顯示新增、刪除與未變動的總數。
這裡沒有送出按鈕，也不需要額外的步驟——你一邊輸入，比較結果就會一邊更新，因此不論修改哪一邊，差異都會立刻重新計算。如果要重新開始，只要清空兩個方塊，結果就會跟著一起清空。因為這兩段輸入內容都是在本機用 JavaScript 處理的，所以從你按下第一個按鍵開始，這個比較過程就是私密的。
解讀輸出結果：+ / - 標記與計數
結果區域使用三種視覺狀態，一眼就能看懂，即使是純文字備註，或是對色盲使用者來說也一樣清楚，因為每一個變動的那一行本身，也都帶有開頭的 + 或 - 符號。
| 標記 | 意義 | 出現時代表什麼 |
|---|---|---|
| + | 在右邊（Changed）方塊中新增的行 | 不存在於 Original 中的新內容 |
| - | 從左邊（Original）方塊中移除的行 | 存在於 Original 中，但不存在於 Changed 版本中的內容 |
| （無標記） | 行未變動 | 在該位置上，兩側的文字完全相同 |
結果旁邊的摘要，會加總出三個累計數字：新增的行數、刪除的行數，以及未變動的行數。如果你只在一份長檔案的中間修改了一行，這些數字能讓你一眼就看出文件其餘部分是否維持完整，並且在你真正讀到任何一行之前，就先讓變動的規模一目瞭然。
瀏覽器版差異比對工具的實際使用情境
處理 Google 地圖時間問題所用的同一套「比較兩個時間點」邏輯，也能處理範圍廣泛的各種文件任務。
- 程式碼提交前的審查：把上一次提交的版本貼在左邊，把目前的工作副本貼在右邊，就能確切看出你即將發布出去的是哪些行。
- 設定檔與 dotfile 變更：檢查團隊成員或部署腳本，在 nginx.conf、package.json，或 Kubernetes 清單檔中改動了什麼。
- 文章、合約與電子郵件的草稿比對：在送出之前，抓出悄悄被改動過的措辭。
- 驗證複製貼上的完整性：確認從終端機、記錄檔或聊天視窗貼上的一長段內容，沒有遺漏或重複某些行。
- 確認兩份匯出的檔案是否一致：比對兩次建置結果、兩份記錄檔匯出，或兩份 CSV 匯出檔案的輸出內容。
- 稽核範本：把一份空白範本，拿去和一份已填寫完成的版本比較，確認每一個必填欄位都已經填好。
對於使用 Git 的開發者來說，關於分支層級比較更深入的教學，可以參考 How to Check the Difference Between Two Git Branches Online；而 Linux 命令列的對應做法，則涵蓋在 How to Check the Difference Between Two Files in Linux 中。
隱私、限制，以及差異是如何被計算出來的
完全在 JavaScript 中執行的瀏覽器版差異比對工具，會把你貼上的兩段文字，留在你自己的裝置上——不需要上傳、沒有伺服器來回傳輸，除了關閉分頁之外，也沒有任何東西需要清除。這讓一個客戶端版本的差異比對工具，能安全地用在私有原始碼、內部設定、尚未發布的草稿，以及機密文件上——對這些內容來說，把位元組送到遠端後端，根本就是不可能的選項。
在底層，這種逐行比較使用的是 LCS 動態規劃演算法，也就是驅動 Unix diff 與 Git 比較畫面的同一套方法。LCS 會找出以相同順序出現在兩個版本中的最長行序列；不在這個共同骨幹內的所有內容，都會被回報為新增或刪除。這麼做的實際好處是：在一份長文件中間的單一一次修改，只會被標示成那一行，而不會讓它之後的每一行都被標記成已變動——對齊結果，會穩穩地錨定在真正相符的那些行上。
有兩個實際的限制值得了解。第一，這是行層級的差異比對，而不是字元層級的：只要一行文字有哪怕一個字元改變了，整個舊的行都會顯示為刪除，整個新的行都會顯示為新增，這樣你就能把兩者並排看到，再手動找出確切的修改位置。對於原始碼、設定檔、記錄檔、JSON、CSV、一般文章與 Markdown 來說——只要有意義的變動單位是「行」——這就是合適的精細程度。第二，隨著輸入內容增加，LCS 比較所需要的記憶體，也會成比例增加。對於日常的檔案、程式碼與文件來說，這個比較幾乎是即時完成的，並且會隨著輸入即時更新；但對於非常龐大的輸入內容（好幾千行以上）來說，瀏覽器就需要在你的裝置上使用成比例增加的記憶體，因此改用檔案中較小的一部分來處理，會是比較乾淨的做法。