你的 Brewfile 是不是也在做白工？我清掉了 76 行才發現的事

本篇是「一鍵搞定新 Mac」系列的第 5 / 9 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。

每隔一段時間我會整理開發環境，這次翻出 Brewfile 來瘦身，結果發現一個蠻傻的問題：我的 Brewfile 一直在備份 VS Code Extensions，但 VS Code 自己早就有 Settings Sync 了。

事情是怎麼發現的

我用 brew bundle dump 產生 Brewfile 備份開發環境，檔案有 202 行，其中 76 行長這樣：

vscode "dbaeumer.vscode-eslint"
vscode "esbenp.prettier-vscode"
vscode "astro-build.astro-vscode"
...（再 73 行）

看到這一大坨就想：等等，這些不是 VS Code 登入 GitHub 帳號就會自動同步嗎？

確認 Settings Sync 有沒有在運作

其實很簡單，看這個資料夾有沒有內容：

ls ~/Library/Application\ Support/Code/User/sync/

如果裡面有 extensions、settings、keybindings 這些子目錄，就代表 Settings Sync 正在運作。如果是空的，去 VS Code 按 Cmd+Shift+P 搜尋 Settings Sync: Turn On 開啟就好。

清理方式

確認 Settings Sync 有在跑之後，一行指令清掉所有 vscode 行：

grep -v '^vscode' Brewfile > Brewfile.tmp && mv Brewfile.tmp Brewfile

之後每次 dump 記得加 --no-vscode：

brew bundle dump --force --no-vscode

結果

Brewfile 從 202 行瘦到 117 行，少了 38%。不是什麼驚天動地的優化，但重點是：這 76 行從來沒有發揮過作用——我每次換電腦都是靠 VS Code Settings Sync 還原 extensions，Brewfile 裡的 vscode 行根本沒人理。

反思：工具的職責要分清楚

這件事的本質是兩個工具在做同一件事，但你只信任其中一個。

Homebrew 的職責是管理系統層級的軟體安裝（CLI 工具、app、服務），VS Code Settings Sync 的職責是管理編輯器的狀態（extensions、設定、快捷鍵）。brew bundle dump 預設會把 VS Code extensions 也撈進來，看起來很貼心，但實際上這份清單永遠不會是你真正用來還原 extensions 的來源。

這讓我想到一個更廣的原則：備份和同步不是越多越好，重複備份只會製造維護負擔和錯誤的安全感。

另外順便整理了 Brewfile 裡其他用不到的工具（hugo、cocoapods、php 等），但那是另一個故事了。