兩個文字版本之間的差異流體量檢查，是指將原始與修訂後的文字貼到逐行比對工具後，所產生的新增、刪除或未變更的行數累計結果。這個結果讀起來就像程式碼、設定檔與文字的「汽車油尺」：一眼就能看出改了多少、在哪裡改、哪些保持原樣。在底層運作中，比對檢查器會使用最長共同子序列（LCS）演算法對齊兩個輸入內容，這也是 Unix diff 以及 Git、GitHub、GitLab 比較檢視背後所用的同一種動態規劃技術。LCS 會找出兩個檔案中以相同順序出現的最長連續行，然後把這個共享骨幹以外的內容全部回報為新增或刪除。這種對齊方式至關重要：在長檔案中段進行的一次編輯，只會被標記為一行變更，而不是該位置之後的每一行。輸出結果會在新增行前方加上 +，在刪除行前方加上 -，並彙整各類別的行數統計。這整個過程完全不需要伺服器往返——所有比對都在瀏覽器中執行。
「差異流體量」對文字而言代表什麼
在汽車維修領域，「檢查差異流體量」是指量測密封齒輪箱內有多少潤滑油——這個單一數值能讓技師判斷系統是加滿、偏低或全空。將同樣的概念轉換到文字上，「差異」變成兩個版本之間可量測的差距，而「流體量」則是該差距的大小。Diff Checker 會以三個數字回報這個差距：新增了幾行、刪除了幾行、以及未變更的有幾行。這個三項數字摘要就是數位版的油尺讀數：一眼就能看出兩個檔案是幾乎相同、稍微修改，還是徹底重寫。
在電腦領域中，「differential」一詞的出現比汽車機械差速器還早了一個多世紀。它單純代表「與差異相關」。因此，diff 工具就是任何能把這個差異呈現出來的工具。逐行比對變體對開發者特別有用的原因在於它的細粒度：它把每一行視為最小且有意義的單位，這正符合人類實際編輯程式碼、設定檔、日誌、JSON、CSV 與結構化文字的方式。只要兩行之間有任何一個字元不同，舊行就會顯示為刪除、新行顯示為新增，因此你能並排看到兩者並精準定位編輯位置。這對原始碼、設定檔、日誌和 Markdown 來說是恰到好處的層級，也是 Unix diff 工具自 1970 年代以來一直採用的方法。
如何檢查兩段文字之間的差異流體量
需要量化兩段文字版本之間的差異嗎？完整流程都在瀏覽器分頁中執行，並在你輸入時即時更新。請依照下列步驟操作：
- 在瀏覽器中開啟 Diff Checker。
- 將原始文字貼到左側標示為「Original」的方框中。
- 將新版本貼到右側標示為「Changed」的方框中。
- 閱讀兩個方塊下方出現的逐行結果：每行前方會加上 +（新增於新版本中）、-（從原始版本中刪除），或無標記（未變更）。
- 查看結果上方或旁邊的即時摘要，取得新增、刪除與未變更行的總數。
- 編輯任一方框，即可在你調整輸入內容時即時觀察差異重新計算的過程。
這就是完整的操作流程。沒有上傳、沒有送出按鈕，也不需要等待伺服器回應。三項數字摘要就是「流體量」的讀數——一個可快速掃讀的答案，直接告訴你兩個檔案實際上有多麼不同。
讀懂行標記與計數
diff 輸出是用來快速瀏覽的，而不是逐行細讀的。這個慣例沿襲自 Unix diff 和 Git commit 檢視，所以任何檢視過 pull request 的人都會立刻認出來：
| 標記 | 意義 | 需要確認的事項 |
|---|---|---|
| + 行 | 出現於新版本中，原始版本中沒有 | 確認這是預期中的新增 |
| - 行 | 出現於原始版本中，新版本中沒有 | 確認這是預期中的刪除 |
| （無標記） | 兩個版本之間完全相同 | 確認它仍錨定在正確的位置 |
每個標記旁的摘要計數讓你一眼看出「流體量」。一個有 200 行未變更、3 行新增的檔案屬於「滿」——幾乎相同。一個有 50 行未變更、80 行新增的檔案則屬於「低」——大幅重寫。未變更行佔總行數的比例，就是最接近流體量的數位對應指標：高代表兩個版本幾乎相同，低代表其中一個經過大量修訂。由於色彩會與標記前綴配對，即使貼到純文字筆記中，或由患有紅綠色盲的使用者閱讀，輸出結果依然清楚易讀。
LCS 對齊對精準讀數為何重要
Diff Checker 能回報「一行變更」而非「編輯位置之後的每一行都變更」的原因，就在於 LCS 對齊。相較之下，從上到下逐一比較的簡易做法會在第一個不符處停下來，並把後續所有內容都標記為不同：
| 方法 | 對齊行為 | 中段單一編輯的結果 |
|---|---|---|
| 基於 LCS 的 diff（本工具） | 以最長的共享連續行為錨點；只標記變更的行 | 1 行標記為 -、1 行標記為 +；其餘保持不變 |
| 簡易逐行比較 | 從上到下逐一比對，在第一個不符處停止 | 編輯位置之後的每一行都被標記為不同，即使內容完全相同 |
| 字元層級 diff | 回報整段文字中每一個變更的字元 | 對程式碼或文字來說難以閱讀；最適合用於較短的字串 |
根據 LCS 的標準定義，此演算法會找出兩個輸入中以相同順序出現的最長項目序列（Longest Common Subsequence, Wikipedia）。在文字 diff 中，這個序列是由整行構成的，這就是為什麼在 500 行檔案中編輯第 47 行，只會顯示為恰好一處變更，而不是 453 個虛假的差異。同一套演算法也驅動著 Git、GitHub 與 GitLab 的 diff 檢視，因此輸出格式對任何檢視過 pull request 的人都會很熟悉。
逐行 Diff 在開發者工作流程中的定位
只要整行是意義的單位，逐行比對就是恰到好處的細粒度。常見的情境包括：
- 提交前的程式碼審查——確認只有你預期要修改的行被標記出來。
- 驗證隊友在設定檔、伺服器區塊或 CI 定義中所做的變更。
- 比較文章、README、合約或更新日誌項目的兩個草稿。
- 健全性檢查，確認複製貼上、尋找與取代、或檔案串接作業沒有靜默地遺漏或重複行。
- 確認兩個匯出檔案（例如從同一個端點匯出的兩份 JSON dump）在行層級上完全相同。
- 稽核範本與填入完成版本之間的差異——例如發票、已填入機密資料的設定檔、或自動產生的報表。
對於非常大的輸入（數千行以上），LCS 比對會按比例需要更多記憶體，但對日常檔案而言，結果基本上是即時的。若要在 Linux 終端機中執行相同的比對，how to check the difference between two files in Linux 中的相關工作流程會直接使用 diff 工具；而 Diff Checker 則是在瀏覽器分頁中採用同樣的 LCS 方法。
隱私、效能與純瀏覽器處理
兩段文字輸入的整個比對過程完全在瀏覽器內以 JavaScript 完成。不會上傳到伺服器、不會被記錄、也不會在分頁關閉後留存。這讓 Diff Checker 可安全用於敏感性內容，例如私人原始碼、內部設定檔、未公開的文字或機密文件——這些是你絕不會貼進會把內容 POST 到後端的線上差異比對服務中的素材。
比對結果會在你輸入時即時更新，因此你可以編輯任一側，即時觀察行標記重新計算的過程。對日常檔案而言，這代表你問完問題的同時，答案就已經顯示在螢幕上了。關閉分頁後資料隨即消失；重新開啟工具時，你會從空白方框重新開始。這個生命週期就和打開本機文字編輯器再關閉它一樣——你的輸入從未離開這台機器。