在 VS Code 工作流程中，差異檢查工具（diff checker）本質上就是一個外部工具，用來比較文字檔的兩個版本，精確標示出哪些行是新增、刪除或保持不變，然後用大家熟悉的 + 與 - 標記來顯示結果。開發人員在需要檢視重構結果、確認同事的修補程式，或是在把程式碼片段貼回編輯器前做最終確認時，就會使用差異工具。VS Code 本身內建一套強大的原生差異檢視，只要執行「Compare with Current」指令，或在原始檔控制面板中點選被修改的檔案就會開啟；此外，編輯器也支援 Partial Diff 和 Diff Tools 等擴充功能，來獲得更細緻的控制。像 Lizely Diff Checker 這類瀏覽器版的選項，則能與這些內建功能並行使用，適用於你想在另一個視窗、另一台機器上查看結果，或不想額外安裝任何軟體的情境。
為什麼開發人員會在 VS Code 中尋找差異檢查工具
「diff checker in VS Code」這個說法通常涵蓋以下三種情境。第一，開發人員想要快速比較兩個不相關的程式碼片段，例如重構前與重構後的某個函式，而不想為了這個動作執行一次 Git 提交。第二，有人在通訊軟體中檢視同事貼過來的程式碼，需要精確指出哪些行被修改了。第三，學習者正在試驗程式碼，希望立即以視覺化的方式看到自己的編輯究竟帶來了什麼改變。VS Code 內建的差異檢視能妥善處理第一種情境，但它要求兩個版本都必須以檔案形式存在於磁碟上；當其中一個版本其實只存於剪貼簿紀錄、說明文件頁面或 Stack Overflow 解答時，這個限制就會造成額外的操作摩擦。瀏覽器版工具則消除了這層摩擦，因為它能直接接受貼上的文字，放進並排的兩個輸入框中。
另一個常見的動機是「可攜性」。開發人員經常在個人筆電、共用工作站與遠端開發環境之間切換，在每台機器上都設定擴充功能既繁瑣又耗時。基於瀏覽器的差異工具只要在能執行現代瀏覽器的地方就能使用，無須登入，也不必在本地安裝。這讓它在結對程式設計、技術面試或客戶支援對話等不便安裝軟體的場合中，做臨時檢查時特別好用。
VS Code 內建的原生差異功能
在動用任何外部工具之前，先了解 VS Code 原生提供了哪些功能會很有幫助。這款編輯器本身就內建了多項與差異相關的能力。
| 功能 | 觸發方式 | 最適合用途 |
|---|---|---|
| 檔案差異檢視 | 在總管中對檔案按右鍵，選擇「Compare with Saved」或先選「Select for Compare」再選「Compare with Selected」 | 比較正在編輯的檔案與最近一次儲存版本之間的差異 |
| Git 變更檢視 | 開啟原始檔控制面板，點選被修改的檔案 | 檢視 Git 提交中已暫存或未暫存的變更 |
| 比較作用中檔案與剪貼簿 | 從命令選擇區執行「File: Compare Active File with Clipboard」指令 | 將目前緩衝區與複製的文字進行差異比較 |
| 行內變更指示器 | 在任何被修改檔案的裝訂邊（gutter）預設啟用 | 一眼看出哪些行被編輯過 |
| 時間軸檢視 | 為任一檔案開啟時間軸面板，即可查看本機歷史紀錄與 Git 歷史 | 追蹤單一檔案隨時間演變的歷程 |
上述功能足以涵蓋編輯器內大部分日常的差異檢查需求。唯一的取捨是，這些功能都要求檔案處於開啟狀態，而且其中有幾項還仰賴工作區中必須先初始化 Git。當你需要快速比較兩段飄忽不定的文字區塊時，就不得不先把內容存到暫存檔，或是改用輔助工具。
如何在瀏覽器中執行差異檢查
當 VS Code 的原生選項顯得殺雞用牛刀時，Lizely Diff Checker 會在新分頁中為你提供一個聚焦的、雙窗格的比較介面。整個流程刻意設計得極為精簡，讓你能貼近自己的編輯器，同時依然得到乾淨俐落的結果。
- 在新分頁中開啟 Lizely Diff Checker 頁面，讓 VS Code 與之分頁並排可見。
- 從 VS Code 複製文字的原始版本，貼到頁面左側的「Original」輸入框中。
- 複製新增或修改後的版本，貼到右側的「Changed」輸入框中。
- 閱讀兩個輸入框下方逐行顯示的比較結果。以 + 號開頭的行表示新增，以 - 號開頭的行表示刪除，沒有標記的行則表示未變動。
- 查看結果底部的摘要，會回報本次比較中新增、刪除與未變動的行的總數。
- 如果需要手動套用變更，或是想把精確的差異分享給同事，可以從結果中複製任何一行貼回 VS Code。
由於此工具完全在瀏覽器中執行，比較過程會在本地完成，無須將文字上傳到伺服器；當你正在處理專屬程式碼或尚未公開的功能時，這一點格外重要。只要分頁保持開啟，結果就會持續顯示，因此你可以反覆修改「Original」或「Changed」輸入框，觀察差異即時更新。
瀏覽器版工具勝過內建差異功能的時機
在某些特定情境下，開啟瀏覽器版差異工具會比設定 VS Code 的原生工作流程更為迅速。當你正在檢視一段包含「修改前 / 修改後」程式碼範例的 pull request 說明時，把兩段內容複製到差異檢查工具中，會比建立兩個暫存檔並進行比較來得快。當你正在偵錯某項設定變更，想確認剛重寫的 YAML 仍符合原本的結構綱要時，差異檢查工具的逐行檢視能讓結構性的錯誤一目了然。當你透過螢幕分享進行結對程式設計，而隊友想要清楚看見究竟改了哪些地方時，比起藏在 VS Code 中的面板，直接指著瀏覽器分頁會更容易說明。
Lizely Diff Checker 也能與其他瀏覽器版的開發者工具良好搭配。例如，你可以先將 JSON 酬載送進 JSON Formatter 進行美化排版，把原始版本和新版本都跑過一次格式化，再把兩邊的格式化結果放進差異檢查工具中比對，藉此找出細微的結構性變動。XML 也能套用類似流程——XML Formatter 能產生一致的排版，讓差異輸出更易閱讀。
常見的差異標記與其讀法
大多數差異工具（包括本文介紹的工具在內）都沿用一套源自早期 Unix diff 指令的共通視覺語彙。理解這些標記後，原本一片花花綠綠的文字牆就能變成一個清楚的故事。
| 標記 | 含義 | 典型用途 |
|---|---|---|
| + | 該行出現在新版本中，但未出現在原始版本中 | 新函式、新設定鍵、新引入的模組 |
| - | 該行出現在原始版本中，但未出現在新版本中 | 被刪除的程式碼、被移除的選項、被停用的分支 |
| （無標記） | 該行在兩個版本中完全相同 | 作為定位參考點的上下文行 |
| 摘要計數 | 新增、刪除與未變動行的總計 | 一眼掌握變更規模 |
由上至下依序閱讀差異結果，等同於反向閱讀一段提交訊息：每一處刪除都對應其 - 標記所在的位置，每一處新增也都對應其 + 標記所在的位置。當多處變更彼此相鄰時，會被視為同一個變更區塊（hunk）來處理，即使它們實際上影響的是不同行；這也呼應了 Git 格式化修補檔的方式。
讓差異結果更乾淨的技巧
幾個小習慣就能讓比較結果明顯更整潔。貼上之前先統一換行符號，尤其當其中一個版本來自 Windows、另一個來自 macOS 或 Linux 時更是如此，因為混雜的換行符號會讓每一行都被誤判為有變更。記得修剪行尾的空白字元，因為行末多出一個空格就足以讓該行被標記為已變更，即使實際內容完全相同。如果要比對的是程式碼，請從 VS Code 內部直接貼上文字，而不是從已渲染的說明文件頁面貼上，因為渲染後的頁面常夾帶行號或複製按鈕，會引入多餘的字元。
面對較大的檔案時，請以邏輯段落為單位分批貼上，而非一次貼入整份檔案，這樣不僅能維持結果的可讀性，也能讓你一次專注於一個區段。若需要比較兩個篇幅較長的檔案，這份以瀏覽器差異檢查工具在 VS Code 中比較文字差異的配套指南會介紹幾種處理多段比較時不致迷失方向的操作模式。
在原生與瀏覽器差異工作流程之間取捨
兩種做法並不互斥。當兩個版本都已作為檔案存在於工作區中、當你正在檢視一筆實際的 Git 變更，或當你想透過鍵盤快捷鍵逐步檢視各個變更區塊時，VS Code 內建的差異檢視仍是首選工具。當有其中一個或兩個版本只以剪貼簿中的文字形式存在、當你需要把結果顯示在第二個螢幕上，或是無法安裝任何擴充功能時，瀏覽器版差異檢查工具才是正解。兩種工作流程都能隨手備用，就能依工作性質挑選最輕量的工具，而不是把每次比較都硬塞進同一種形式。
想進一步了解，請參閱免用 VBA，數分鐘自訂 Excel 鍵盤快捷鍵。
想進一步了解，請參閱如何格式化 JSON 以提升可讀性與除錯效率。
想進一步了解，請參閱如何在線上比對兩個 Git 分支之間的差異。