去年大促前一天，我把本地調好的 nginx 設定同步到線上，只改了兩行。上線後連線數很快打滿，翻回設定檔用眼睛一行行掃，掃了近二十分鐘沒看出問題，最後是同事把兩份檔案並排貼出來才看到：第三十幾行有一句 worker_connections 64，而倉庫裡那份是 1024。我當時盯著的是自己改過的地方，對「看起來眼熟」的整塊內容完全沒有防禦。從那以後我給自己定了條規矩：只要是兩份文字要確認異同，就不再用眼睛比。這類需求比想像中頻繁——設定回滾、合約回傳、文案終稿、名單核對，本質都是同一件事。
一、哪些場景真的需要逐行比對
- 設定與環境：本地/測試/線上三台機器的設定檔，或者同一個檔案改動前後的差異，重點是有沒有多出或被覆蓋的行。
- 合約與文件：對方回傳的 Word 轉成純文字之後，看條款措辭被改動的位置，尤其是金額、期限、責任上限這類行。
- 清單與名單：兩批匯出資料的增刪項，比如上下架商品 ID、訂閱使用者名單。
- 程式碼與腳本：臨時改動自查、合併前核對，或者別人提交的修補是否只動了該動的部分。
這幾類的共同點是：差異數量少、位置隨機，但代價大。1024 變成 64 只是三個字元的事，肉眼在滿屏相似文字裡幾乎抓不到它。
二、四種辦法的代價對比
| 做法 | 200 行文字大約耗時 | 能看到什麼 | 主要風險 |
|---|---|---|---|
| 肉眼上下捲動比對 | 15–25 分鐘 | 顯眼的大段增刪 | 漏掉單字元改動，注意力先入為主 |
| Word / 編輯器「尋找重複行」 | 5–10 分鐘 | 同一段文字內部重複 | 不是兩份檔案之間的比較 |
| 命令列 diff | 2–5 分鐘 | 逐行增刪，輸出精確 | 要記參數、處理檔案路徑與換行符 |
| 瀏覽器裡貼上兩份文字逐行比對 | 1–2 分鐘 | 醒目標示的增刪行與行數統計 | 需要先把兩邊都貼全，別漏貼 |
命令列 diff 的結果最嚴謹，但每次都要開終端機、找路徑、判斷該用哪個參數，臨時需求常常就卡在這一步。我的處理是把網頁版當作第一道篩查：文字比對左右各貼一版，新增行綠色、刪除行紅色，同時給出新增/刪除/修改的行數統計。那個統計數字很關鍵——它會告訴你「這次改動一共動了 17 行」，而我原本以為只有 2 行，數字對不上就說明改動本身失控了。
三、讓比對結果可信的四件前置工作
- 統一臉行符。Windows 端的 CRLF 和 Linux 端的 LF 一旦混在一起，逐行比對會把整份檔案判成「全刪全增」，幾百行紅綠毫無意義。這是新手最常見的誤報來源。
- 統一縮排。Tab 與 4 個空格混用會讓同一行內容看起來不同。比程式碼前先把兩邊縮排策略對齊，避免把格式差異誤讀成邏輯差異。
- 順序無關的內容先排序。兩份名單只是排列不同、集合完全一致時，先排序再看差異。文字排序去重可以按升冪整理並順便去重，排完再比，「假差異」能一下少掉大半。
- 比完再確認「數量」而不只是「位置」。把新增行數和刪除行數記下來和預期對照。改動 3 行的任務，結果統計是 40 行，一定要先解釋清楚這個差值再上線。
順帶說一句隱私：文件、合約和原始碼這類內容，我傾向選在瀏覽器本機完成比對的方案，不走伺服器端傳輸，也不用擔心內容被留存；這一點在選工具時比功能多寡更重要。
四、除了找不同，比對還能回答這些問題
- 範本有沒有被改：把渲染結果和基準版本比，輸出是否只多了預期的變數。
- 資料匯出是否穩定：同一份查詢兩次匯出的結果對比，行數應完全一致。
- 字典/列舉是否漏項：新舊版欄位清單對比，新增欄位有沒有同步到文件。
- 文案有沒有改過頭：初稿和終稿比一次，再配合字數統計看增減幅度是否超出約定範圍。
讀統計數字比讀醒目標示更快收斂。那次排查我給自己定了一條流程：比完先只看三個數——新增幾行、刪除幾行、改動幾行，再去看位置。預期只動 2 行而統計顯示 15 行時，先別讀內容，回去查換行符和縮排；確認基準乾淨之後，剩下的差異才是真實的改動。反過來說，如果統計只有「1 刪 1 增」，那基本就是某個值被改了，一眼就能定位到 worker_connections 這類單參數變更。
散文類文字要單獨對待。從 Word 或 PDF 裡複製出來的段落帶的是版面軟換行，同一句話在兩份檔案裡可能落在不同的行上，逐行比對會把整段標成「全刪全增」。我的處理是把文件變成「一段一行」再比：犧牲排版資訊，換來差異位置準確；比對結論只用來判斷「改了哪幾句」，排版層面的確認還是回到原文裡看。
五、常見疑問
Q：文字比對和 git diff 有什麼區別？
原理一致，都以行為單位。git diff 依賴倉庫和提交歷史，能告訴你「這次提交改了什麼」；網頁版不依賴版本庫，任何兩份隨手能拿到的文字都能比，適合線上檔案和本地副本、別人寄來的附件這類沒有共同歷史的情境。
Q：一段文字裡只改了一個字，會怎麼顯示？
逐行比對是「行」的粒度，那一行有變化就整行標記。所以整行看不出到底改了哪個字元，需要把兩行單獨拎出來比，或者借助按字元拆分的工具。
Q：幾千行的文字能比嗎？會很慢嗎？
可以。真正影響體驗的不是行數而是差異數量：一份 3000 行但只改 5 行的檔案比 300 行改了 200 行的檔案更容易讀。差異過多時，先做前面說的排序和格式統一，把雜訊壓下去。
Q：貼上的內容會被上傳儲存嗎？
這取決於具體工具。我用的這種是在瀏覽器本機完成比對，文字不發往伺服器端，處理合約和原始碼時更放心。判斷方法是開啟開發者工具的網路面板，看比對過程中有沒有新的請求發出。
Q：兩份文件格式不同（Word 和 PDF）怎麼辦？
先都轉成純文字再比，重點保證段落換行位置接近，否則同一句話被拆成不同行數會產生大量假差異。轉換後先掃一眼行數是否在同一量級，再進入比對。
大促那次之後，我把「改設定必須做一次前後對比」寫進了發布清單，成本是十幾秒。真正讓我改習慣的不是這個動作本身，而是那二十分鐘肉眼掃描給了我一個結論：人對「眼熟的整塊內容」完全沒有抵抗力，差異必須靠機器標出來才看得見。