把部落格後台搬進 VS Code：修圖、上傳、管理圖片、AI 產生分類與標籤一次搞定
在之前的 自架 WordPress 用了 7 年，最後又回到自己寫程式，雖然回到用 VS Code 編輯文章的模式，但其實還是有個網頁程式介面，用來上傳圖片，還有設定一些文章資訊，例如挑分類、挑相關文章等等，也可以線上編輯文章。
但其實很多時候還是有不少冗餘的操作步驟:
- 在 Photoshop 裡面改圖，然後另存新檔，選擇 webp，選擇存檔位置，然後又要到別的視窗、登入、選擇存檔位置，上傳圖片。
- 管理線上圖片、管理本地圖片，把圖片插入文章，要在多個視窗來回切換，非常浪費生命。
- 有些圖片編輯需求其實非常普通，連開小畫家都太多餘，我還要找小畫家的圖示藏到開始功能表哪邊去了?
- 為了幫圖片取個語意化檔名，還要小心不要撞名，又要花一些時間跟步驟。
既然是在 VS Code 編輯文章，所以做了個 VS Code 擴充套件，在多個視窗來回切換很麻煩? 那就直接修圖、上傳、管理圖片都在同一個視窗做完。大幅提升文章撰寫、圖片管理以及網站管理的效率。
本文介紹一下擴充套件有什麼功能，還有 VSC 擴充套件跟一般的網頁程式又有什麼特殊之處。
擴充套件功能介紹
因為本來已經有一套寫好的網頁程式，所以不用在擴充套件內保存什麼雲端的金鑰、實作整套流程邏輯，有些圖片上傳邏輯就是直接呼叫那邊的東西，在 VS Code 擴充套件內把資料顯示成方便操作的 UI 介面。
影片中還是非常早期的版本，但懶得再重錄一遍，下面大致介紹一下做了哪些功能。
1. 上傳
專業繪圖軟體為了滿足所有人的需求，把一件事拆成許多步驟，在每一個步驟提供了一大堆的選項，像極了家裡的遙控器，現在就像直接做一個一打開電視就看到指定節目指定頻道的按鈕。把繁瑣的圖像處理步驟藏起來，設定值都預先寫好，選完圖片就能直接上傳。
支援圖片的全自動處理與上傳:
- 能快速選擇本機圖片（支援 JPG, PNG, GIF, WebP）
- 可選擇單張或多張，或移除選擇
- AI 命名
- 自動壓縮選項（設定最大寬度，自動轉換成 WebP）
- 多圖一鍵自動轉檔壓縮上傳到雲端
上傳完成後可以直接產生 HTML 語法，或一鍵將圖片標籤插入目前的 Markdown 文章內，完全不需離開編輯視窗。
2. 瀏覽
提供雲端物件儲存服務的檔案瀏覽介面，可以直接在編輯器內查看已經上傳的圖片清單與縮圖。
目前有做的功能:
- 檔名搜尋
- 快速複製圖片網址
- 一鍵插入文章
- 刪除圖片
- 進入圖片編輯模式
- 檢視縮圖
- 刷新目錄
- 用瀏覽器打開圖片
省去在瀏覽器分頁之間，切換雲端儲存空間的繁瑣步驟。
3. 裝置同步檔案
有時候圖片要從手機傳到電腦(我主力是 iPhone 配 Windows)，以前是用 LocalSend 的 app，每次要用時還要另外打開，等兩台裝置都配對到彼此。然後有時候傳完沒按完成，下次要傳還會卡住，有時候則是陷入某種不明的連線錯誤狀態。
既然電腦跟手機都在同一個內網，那就直接讓擴充套件在電腦上啟動一個小型的 Local Server，並產生專屬連線的 QR Code。
手機、平板、其他區網電腦都能透過這個檔案上傳的網頁，直接將手機上的照片影片丟到我的電腦中指定的資料夾。傳完之後再把伺服器關掉。
4. 文章
專為 Markdown 文章撰寫設計的輔助區域。包含：
- Front Matter 管理：快速自動取得/插入文章 ID、編輯標題，還能結合 AI 模型（如 Gemini 等）自動分析內容並產生摘要（Meta Description）。
- 分類與標籤選擇：提供一個介面手動選擇分類、標籤、相關文章，也能利用 AI 自動智慧推薦適合的關聯標籤與相關文章，最後一鍵組合出一整段完美格式化的 Front Matter 自動插入文章的最上方。
- 還做了個 MCP，裡面做了幾個 tool，會自動讀取文章資訊和分類清單，把生成標題、描述...之類的全部用 AI 跑完。
理論上把文章本文打完，就能直接讓 AI 把剩下的事做完，但後來還是很少用這個全自動功能。
因為用便宜或免費 AI 模型，生出來的文章標題、描述之類的效果令人很不滿意，一點靈魂都沒有。大概只適合拿來生成歲月靜好、和和氣氣、毫無個性的商業文章。
不過 AI 是不會負責背鍋的，AI 效果不好，只能怪我這個人類文章不夠直白、文章太長耗 token，或是沒有試到最適合每種模型的 prompt。
5. 指令
部落格專案的 package.json 內設定的指令多到記不起來，所以把指令&選項參數直接整合成一堆 UI，例如:
- 建置或壓縮 CSS/SCSS/JS
- 呼叫某些線上 API
- Markdown 轉 HTML (這個後來直接在 git hook pre-commit 做掉，文章草稿目錄有檔案變動，就自動生成)
- 啟動本地端測試機的 Docker
- 備份 Threads 文章
還有其他指令就不列了。
6. 圖片編輯
在側邊欄選擇本地圖片或雲端圖片後，可直接進入圖片編輯器，編輯完直接上傳。
功能包含:
- 圖片裁切
- 馬賽克筆刷
- 插入方塊(填滿方塊可用於遮擋資訊，鏤空方塊可用於標記區域)
- 加箭頭
- 圖片旋轉/水平翻轉
- 本地儲存(覆蓋原檔、另存新檔)
- 雲端儲存(覆蓋原檔、另存新檔)
- AI 生成檔名
這樣既保留了自架部落格的優點(所有檔案在本機都有一份，不怕平台跑路)，又能把所有文章編輯流程中會用到的操作，通通整合到一起。
以下紀錄分享一些 VS Code 套件的開發筆記:
建立範例專案
只是要做一個有自己名字的 VS Code 擴充套件，可以使用 VS Code Extension Generator，安裝&執行 npx --package yo --package generator-code -- yo code之後，會引導完成一個基本的 VS Code 擴充套件專案目錄架構。
真的要做些什麼功能，可以參考微軟官方提供的 vscode-extension-samples。裡面有幾十種範例，每個範例還會列出用到的 API，非常適合新手入門。
當然也可以隨便找個 Copilot, Antigravity, Codex 之類的本機 coding agent，直接向 AI 提出想法開始開發，展開疊床架屋猛加功能的旅程。
探索後發現，要開發一個 VS Code 擴充套件，可以用熟悉的 Web 技術（HTML / CSS / JavaScript），但整體架構和一般網頁程式有幾個極大的區別。
樣式無縫融入 VS Code 的主題變數
在寫網頁前端時，要把預設的灰色按鈕、輸入框等表單物件，從醜醜的預設樣式調整成客製化樣式，就是一個工程問題。少則寫幾十行起跳的CSS，大到引入一些 UI framework，然後被開發者在聖誕節送彩蛋惡搞。
一開始發現程式碼裡並沒有撰寫太多複雜的色彩CSS、跨平台的判斷規則，但做出來的 UI（按鈕顏色、輸入框、文字）不管換到什麼地方，都跟 VS Code 幾乎融為一體?
分別是 Windows 上的 Cursor/VSC，還有 Mac OS 上的 VSC
這是因為 VS Code 有一堆內建的 CSS 變數（CSS Variables）可以讓我們的 Webview 網頁使用，例如：
var(--vscode-font-family)：跟隨編輯器設定的標準字體。var(--vscode-button-background)：取得編輯器當前主題的按鈕主色系。var(--vscode-editor-foreground)：目前的文字顏色。
當我切換 VS Code 編輯器的深色/淺色主題時，只要套件的 CSS 使用這些變數，顏色也會自動切換。不論是哪一種佈景主題都會像是原生內建的功能，減少突兀感。
相關補充資源:
- VS Code CSS Theme Completions 一個 VS Code 套件，可以在寫 CSS 時自動提示還有哪些內建變數能用。
- Theme Color | Visual Studio Code Extension API 一個大表，解釋每一種顏色名稱會顯示在哪裡。
- List of CSS variables accessible in an extension WebView #2060 關於變數清單大表的討論
沙盒限制與 Message Passing 架構
網頁有前後端(跑在client side browser的程式，跟跑在伺服器上的程式)，到了 VS Code 擴充套件，勉強也能分成跑在 Webview 的前端和 Extension Host 後端，Extension Host 在官方中文翻譯成延伸主機。
前端 Webview 的 JS 不能直接用 fs.readFile 去讀取電腦的檔案，也不能直接存取 process.env 讀取系統環境變數。
如果需要顯示這些系統變數或硬體狀態，必須靠後端的 Extension Host 讀取完畢後，再把資料透過 postMessage 傳遞給前端 Webview 顯示。
範例：將系統變數傳給前端顯示
// 1. 在後端 Extension Host (Node.js 環境) 中讀取並傳送：
const systemEnv = process.env;
webviewPanel.webview.postMessage({
command: 'showEnvData',
data: systemEnv
});
// 2. 在前端 Webview (前端瀏覽器環境) 中接收並印出：
window.addEventListener('message', event => {
const message = event.data;
if (message.command === 'showEnvData') {
console.log('從後端收到的環境變數:', message.data);
document.getElementById('env-display').innerText = JSON.stringify(message.data, null, 2);
}
});
呼叫系統指令：前端 Webview 本身沒有權限直接使用 child_process 執行 Shell 或 Terminal 指令。
如果擴充套件需要呼叫外部 CLI 工具（例如本文的 VSC 套件有實作一個用本機的 Gemini CLI 幫圖片自動 AI 命名的功能），必須透過 Message Passing 把指令傳給後端的 Extension Host，如以下範例。
範例：請後端代為執行本機的 Gemini CLI 命名圖片
在前端 Webview (前端瀏覽器環境) 中發送請求：
vscode.postMessage({
command: 'runAiRename',
filePath: 'C:/temp/image.png'
});
在後端 Extension Host (Node.js 環境) 接收後執行 CLI：
import * as child_process from 'child_process';
webviewPanel.webview.onDidReceiveMessage(message => {
if (message.command === 'runAiRename') {
// 在後端擁有完整權限，調用 child_process 執行終端機指令
const cmd = `gemini-cli "請幫我分析這張圖片並產生一個只有小寫英文和dash的檔名" "${message.filePath}"`;
child_process.exec(cmd, (error, stdout, stderr) => {
if (error) {
console.error(`執行失敗: ${error}`);
return;
}
// 執行完畢後，再把結果傳回前端顯示
webviewPanel.webview.postMessage({
command: 'aiRenameResult',
result: stdout.trim()
});
});
}
});
有些在傳統網頁瀏覽器能做的事情，在 VS Code 版本的 Webview 中可能水土不服，因為有不同作業系統差異。
例如存取剪貼簿，在 Windows 上 Webview 的 navigator.clipboard.readText() 可能會因為缺少使用者明確手動授權而直接報錯，但在 macOS 上或許能順利執行（或反之）。因此，凡是涉及系統資源存取的動作，最好的做法都是交由 VS Code 的 Extension Host 機制來處理。
擴充套件裡面用到的相依套件(好繞舌)，也可能有跨平台問題，如本文介紹的套件有一些圖片處理功能，有用到 sharp，在 Windows 上跑得好好的，在 macOS 安裝後完全打不開，又需要用 sharp-libvips 處理。
另外還有關於 Message Passing 傳遞的限制與 Timeout：
- 非同步特性：
postMessage是一種 fire-and-forget（射後不理）的操作，它本身沒有像 Ajax/Fetch API 那樣自帶的 Callback 或超時中斷 Timeout 機制。 - 自訂 Timeout 實作：VS Code 底層並沒有為
postMessage設定硬性的連線超時限制。
如果需要發送 API 請求到外部網站、執行長時間腳本，前端 Webview 必須自己設定 setTimeout 來管理等待頁面，自己設計例如 10 秒後沒收到擴充主程式回傳的對應訊息，前端就自行解除 loading 狀態並報錯之類的機制。Extension Host 也要 Node.js 中處理指令執行的超時異常。
可延伸執行任何程式語言，不僅限於 Node.js
延續上一點，雖然前端 Webview 受到沙盒限制，但負責當大腦的滿血 Node.js 擴充主程式 (extension.ts / Extension Host) 卻可以無限制地存取電腦。
我們可以將 VS Code 的前端 UI 當成一個 GUI 遙控器，點擊按鈕後，由擴充主程式去呼叫電腦裡任何已安裝的環境或語言，執行平常在 CLI 終端機打的指令。
不只是本機腳本，結合 Node.js 與底層指令，還可以:
- 可以直接利用
https://協定發送請求去外部網站抓資料 - 利用
ssh://機制操作遠端伺服器 - 執行
git push、curl、lftpFTP 傳檔等跨網路任務 - 呼叫本地端
docker服務
VS Code 不只是程式碼編輯器，還能當成對本機程式&外部服務聯絡的樞紐中心。
狀態保存與持久化登入機制 (State & Auth)
一般全端 Web 網站架構，常會依賴 Browser Cookie、PHP Session 之類的機制來維持使用者的登入狀態。但在 VS Code 擴充套件中，這些傳統網頁機制並不適用。
例如要做一個「需要帳號密碼登入才能使用的擴充套件」?
Webview 就像無痕瀏覽器（Cookie 無法跨工作區/重開機存活），Webview 中雖然可以使用 document.cookie 或 localStorage，但它們的生命週期極其不穩定。
每次關閉 Webview 面板(例如切換到別的檔案再切回來)，它內部的 DOM 和 JavaScript 變數預設都會重新初始化。即使資料當下存進去，重開 VS Code 或是換一個專案資料夾開啟套件，Cookie 跟 Storage 往往就會直接被清空，完全無法達到「持久化登入」的目的。
想要持久，就要用這個瑪卡......講錯了，是要用 Extension Context 的專屬安全儲存 API:
context.globalState：類似跨專案的 LocalStorage，適合存一些全域的雜湊設定（例如：是否開啟某個提醒）。context.workspaceState：針對目前打開的這個專案資料夾存放設定，換個專案資料夾就不共享。context.secrets(SecretStorage)：這是非常重要的一點！如果要存放使用者的登入 Token、金鑰或是密碼，一定要將其保存在context.secrets。它是與作業系統層次的安全儲存區域（Windows 的認證管理員 Credential Manager、macOS 的鑰匙圈 Keychain）綁定的，能夠最高等級加密保護敏感憑證。
我們必須利用 Extension Host 把登入狀態（Token、API 金鑰或甚至 Cookie 字串）存放在些地方，即使關閉 VS Code 電腦重開機也不會消失。
因此，實作登入流程通常是：Webview 向使用者顯示登入表單 -> 透過 postMessage 傳遞帳密給 Extension Host -> Extension Host 向遠端伺服器驗證取得 Token (或 Session ID) -> 存入 context.secrets 中**。
下次打開套件時，主程式直接從 secrets 撈出憑證，並在 Node.js 中使用它來發起 API 呼叫（例如在 request header 放入 Authorization，或是自己組裝 Cookie header 送出），Webview 開啟時只要向擴充主程式請求登入狀態就好，使用者就不需再登入一次了。
使用外部網頁登入
但大家可能也看過例如 Cline 跟一些擴充套件，點擊登入後，不會在 VS Code 裡面輸入帳密，而是打開電腦上的預設瀏覽器，在網頁上授權完畢後，VS Code 會突然彈出一個提示框問「是否允許擴充套件開啟此 URI？」，然後套件就神奇地變成登入成功的狀態了。
這是擴充套件最正統的 OAuth 登入做法，它不僅比在 Webview 裡刻表單更安全，還能直接沿用使用者在 Chrome 上已經登入的社群帳號（不用重新輸入密碼），用到的機制跟上面又不太一樣，實作概念大概是這樣：
- 呼叫系統瀏覽器：在套件主程式中，遇到需要登入的指令時，使用
vscode.env.openExternal(vscode.Uri.parse('https://your-auth-site.com/login'))喚醒使用者的預設瀏覽器（Chrome/Edge）。 - 網頁端驗證與深層跳轉 (Deep Link)：使用者在網頁上完成 Google/GitHub 登入後，網頁伺服器不能像往常一樣跳轉回
https://...，而是要設定重新導向（Redirect）到 VS Code 的專屬深層連結，格式通常為：vscode://我的套件發行商ID.我的套件ID/callback?token=abc...。 - VS Code 接收回應：在套件主程式的
activate中，需要提早註冊一個 URI 處理器 (vscode.window.registerUriHandler)。當使用者在網頁同意跳轉回 VS Code 且按下允許時，這個 Handler 就會接管並解析網址列中的?token=abc，接著一樣把取得的 Token 存進context.secrets中完成登入手續！
套件產生的實體檔案該存在哪裡？(File Storage)
如果套件執行後會產生一份實體檔案（譬如 SQLite 資料庫檔、設定的 JSON 檔、快取圖片檔案），肯定不希望它下次開機就不見。在 VS Code 擴充套件中，檔案絕對不能隨便存在擴充套件自己的安裝資料夾（__dirname）底下，因為每次套件更新，那個資料夾就會整個被清空重置。
如果下次執行時需要根據那個檔案的資訊來執行，VS Code 提供了兩個專屬、安全且保證不會被隨意刪除的儲存資料夾路徑，讓的 Node.js 主程式去進行 fs.writeFile 寫入：
context.globalStorageUri 全域儲存空間
用途：如果這個檔案跟任何特定的專案無關，只要是同一個使用者開的 VS Code 都能共用這份資料（例如：使用者的個人 Profile 頭像快取、全域的 SQLite 字典庫、跨專案生效的基礎設定檔 config.json）。
位置：通常位於使用者的個人資料夾下（類似 ~/.config/Code/User/globalStorage/套件ID/）。
context.storageUri 工作區專屬儲存空間
用途：如果這個檔案只針對目前打開的這個專案（Workspace）有效。離開這個資料夾打開別的專案，讀到的就會是另一份獨立的檔案（例如：針對這個專案掃描後產生的快取分析包 build-cache.json，或是針對這個專案綁定的特定遠端伺服器 .env.local 備份檔）。
位置：通常位於工作區配置下（類似 ~/.config/Code/User/workspaceStorage/隨機工作區Hash/套件ID/）。
實作方式就是在 extension.ts 的 activate 函數中，先確定這個目錄存在（可以用 fs.mkdirSync(context.globalStorageUri.fsPath, { recursive: true }) 建立），然後後續的所有檔案讀寫操作（fs.writeFileSync / fs.readFileSync），都指定存放在這個 fsPath 資料夾底下。
這樣不論套件怎麼更新、電腦怎麼重啟，只要使用者沒把套件徹底反安裝清資料，這個檔案就會一直存在！
VSC 套件可以存 IndexedDB 嗎？有同源概念嗎？
在一般瀏覽器中，IndexedDB 或 LocalStorage 的資料存取權限是綁定 Origin 的(譬如 https://example.com)。
但在 VS Code 的 Webview 中：
- 網域來源 (Origin) 極度不穩定：Webview 運作的特殊協定通常會帶有一個長長的隨機雜湊碼（像是
vscode-webview://01234567-89ab...）。 - 強烈不建議使用 IndexedDB 等前端儲存庫：因為這個來源 ID 在更新 VS Code 版本、重開機、或是重新開啟 Webview 面板時，可能隨時會變動，導致「昨天存在這個網域 IndexedDB 的資料，今天因為被判定為不同網域而再也抓不到」。
替代的現代作法：如果需要存取結構化的大量資料（類似於 IndexedDB 的專案），正確的思路一定是：在 Extension Host 端引入真正的本地資料庫套件（例如 sqlite3、lowdb 等），並將產生的 .sqlite 或 .json 資料庫實體檔案，妥善存放在上一點提到的 context.globalStorageUri 路徑下。
Webview 前端 UI 只是單純的畫面呈現，當需要讀取或寫入一筆資料時，它就負責用 postMessage 向 Node.js 下查詢指令，再接收回傳的結果。
如何做到產生檔案後，讓使用者下載
一般網頁程式如果產生了圖片或報表檔案給人下載，通常會在前端產生一個 <a href="blob:..." download="file.csv">下載</a> 的連結，連結內可能是一個 blob URL 或遠端主機的 URL，然後依賴瀏覽器處理跳出儲存與否的行為。
然而在 VS Code 擴充套件裡，前端 Webview 是無法像瀏覽器的預設下載一樣，無法直接觸發。
VS Code 有更原生系統化的實作方式：
- 前端提出下載請求：Webview 把產生好的檔案資料字串（譬如一個長長的 CSV 或 Base64 字串圖片）打包放入
postMessage({ action: 'saveFile', data: '...' })傳給後端的 Extension Host 主程式。 - 呼叫作業系統原生對話框 API：Node.js 擴充主程式收到要求後，呼叫 VS Code 的專屬 API
vscode.window.showSaveDialog()。這會直接彈出一個原生的「另存新檔」作業系統視窗，還能自訂預設檔名跟副檔名的過濾器，讓使用者去選在他們這台電腦上想存放在哪裡。 - 由 Node.js 寫入檔案並通知：使用者選好儲存路徑（譬如
D:\Downloads\my-report.csv）按下確定後，Node.js 就會拿到這組完整的自訂絕對路徑。接著就是發揮 Node 本色，主程式呼叫強大的fs.writeFileSync(path, data)直接默默並有效率地把資料寫進使用者的硬碟裡。 - 然後跳出一個 VS Code 的通知
vscode.window.showInformationMessage('匯出成功！已儲存在：' + path)。
這就是 VS Code 套件比瀏覽器單純前端更強大，且能深度整合系統的地方，它能直接操作任何想放的檔案位置，而不被強迫受限在瀏覽器下載行為。
擴充套件 UI 設計與佈局的常見名詞與規範
如果不熟悉 VS Code 擴充套件的專門術語，想要新增功能時可能會不知道怎麼下達指示。以下是常見的 UI 區塊，以及其設計限制與相關規範，幫助我們未來溝通更精準：
1. Activity Bar (活動列)
這是 VS Code 最側邊(預設在左側最旁邊)那條直直的圖示列，包含我們常見的檔案總管圖示、搜尋圖示、原始碼控制的那排 icon。只要從這邊點擊我們的「文章編輯工具」圖示，就是馬上使用。
不一定每個套件都要塞一個圖示在這邊，這東西不是必要的，還有N種方法呼叫 VSC 擴充套件中的功能，例如 command palette、快捷鍵、右鍵選單，等下介紹的其他版面位置等。
關於 Activity Bar 圖示的設計鐵律與實作：
- 必須是 SVG 格式：不支援 PNG、JPG 等點陣圖，以確保在高解析度螢幕上縮放不失真。
- 單色線條風格 (Monochrome)：圖示不可以自帶顏色（不能寫死
fill="red"）。通常整個 SVG 必須是形狀乾淨的單色線條。 - 自動適應主題色的魔術：只要 SVG 是單色（通常預設黑色或白），VS Code 的渲染引擎會自動介入幫它上色。在深色主題會自動反白，在淺色主題會變深灰；圖示被「選取（Active）」時，會自動染上主題的高亮色（Focus Color）。這就是為何圖示都能完美融入主題的原因。
如果不會畫 SVG 或是想極度貼近原生，VS Code 有內建一套名為 Codicons 的百種圖示庫。開發時只要這樣打一個代號 $(gear) 編輯器就會顯示成齒輪。想看更多圖示可以查閱代號大表: Product Icon Reference。
VS Code 套件有很多地方，如果要顯示圖示，一定要放一張圖片。至於按鈕或其他介面也要有圖示，最省事的就是直接用 emoji...
2. Primary Sidebar (主側邊欄)
點擊 Activity Bar 上面的圖示後，展開的那一條寬面板塊（例如 Explorer 的樹狀目錄）。我們目前將功能註冊為 Webview View 並掛載在這裡面，這樣就能一邊開著文章進行編輯，一邊從左側存取輔助功能。
3. Editor Title (編輯器標題列 / 索引籤列)
像 Claude 的 VS Code 套件，會在平常上面顯示檔案的頁籤（Tab）最右邊、也就是分割視窗按鈕的旁邊，放上一個專屬的小 Icon（點下去可能抓取代碼給 AI 看或打開特殊面板）。
這個兵家必爭的黃金地段，在 VS Code 的定義中叫做 editor/title 選單。
- 如何出現在這裡：開發者需要在
package.json的menus節點下，針對editor/title註冊一個指令（Command），並綁定一個圖示。 - 條件顯示 (When Clause)：為了避免這個區域被數十個套件塞爆，VS Code 鼓勵且允許透過
when條件來控制圖示什麼時候該出現。例如可以設定when: "resourceLangId == markdown"，讓小按鈕只在正在編輯 Markdown 檔案時才優雅地浮現。
4. Secondary Sidebar (次側邊欄)
VS Code 支援在畫面的另一側開啟另一個輔助的側邊欄。使用者可以手動打開它，這個位置非常適合放一些不會頻繁操作，但時常需要瞄一眼的工具箱。
沒有絕對的左邊或右邊：在 VS Code 裡使用者可以隨意在 Activity Bar 按右鍵，選擇「將活動列移至右側」，這樣那個套件的 Primary Sidebar 就會跑去右邊。
因此寫 Webview UI 時，排版必須是彈性 Responsive 的，不能預設「我的面板一定在左側」。
載入時機與效能 (Loading 很久的原因)：與主側邊欄不同，Secondary Sidebar 經常是被延遲載入的。如果套件把重量級的 Webview (iframe) 塞在這裡，VS Code 要在底層去協調多個套件搶這塊側邊欄資源，渲染順序較低時，就會發生卡頓或白畫面 Loading 特別久。建議在這裡盡量使用原生的 TreeView（輕量），而少放沉重的自訂 HTML。
5. Panel (底部面板)
這通常位於程式碼編輯區的「正下方」，裡面包含了最常使用的「終端機 (Terminal)」、「輸出 (Output)」、「除錯主控台 (Debug Console)」。如果功能會產生大量的文字輸出（例如跑 npm build），通常就會把它印在這個區域。
6. Status Bar (狀態列)
位在 VS Code 最底部那條極度細長的橫條。適合用來放文字提示、狀態燈號（Status Bar Item）。
例如，未來如果想顯示「API 連線正常 🟢」，或是放一個「立刻上傳圖片」的小文字按鈕，就可以將功能放在 Status Bar。
狀態列的左右與優先級 (Priority)：
建立 Status Bar Item 時，開發者必須指定它要放在左邊還是右邊，以及它的排序優先級：
- 左側 (
vscode.StatusBarAlignment.Left)：通常用來放跟整個工作區 / 專案狀態相關的資訊。例如 Git 分支狀態、同步狀態、專案是否正在建置中。 - 右側 (
vscode.StatusBarAlignment.Right)：通常用來放跟編輯器本身 / 當前開啟檔案相關的設定。例如目前的檔案編碼 (UTF-8)、縮排幾格、TypeScript 版本。 - Priority 權重分數：可以給定一個數字（例如 100）。數字越高的項目會越靠近邊緣（越靠左或越靠右），讓重要的資訊不會被擠到中間被隱藏起來。
7. Webview Panel (網頁視圖面板)
如果覺得側邊欄（Sidebar）太窄了，不想要把介面擠在小小的地方，那麼可以選擇使用 Webview Panel。這會直接佔據一個完整的「程式碼編輯器標籤頁（Editor Tab）」空間。
就像一些 Markdown 套件的預覽畫面那樣，適合用來顯示大型圖表或複雜的管理後台。
我用這功能做了一個圖片編輯介面。
8. Command Palette (命令選擇區)
按下 Ctrl+Shift+P (或 Cmd+Shift+P) 彈出的指令輸入視窗。這是 VS Code 中所有功能與指令的入口，我們可以讓任何功能都不依靠滑鼠點擊按鈕，而是將指令（Command）註冊在這裡，純鍵盤操作就能發動。
等下會再提到這玩意，因為這些指令名稱不只是出現在上方命令選單中，還可以用 code --command blog-user-today-editor.某某指令 從其他程式呼叫 VSC。
能夠做出自由移動的小視窗嗎？
上一大段提到 VS Code 畫面上各處的面板名稱，可能會發現所有東西都是黏死在 VS Code 主視窗上的，頂多拖曳調整寬度，或是調整 icon 順序，非常不自由，
如果想做個像桌面便利貼/電子寵物一樣，可以隨意自由拖曳互動的應用，Extension API 沒有提供任何指令讓人憑空創造一個獨立的 OS 層級懸浮視窗。透過擴充套件畫的所有 UI，最初一定都得掛載在上述的 Sidebar、Panel 或是 Editor Tab 裡面，乖乖聽從 VS Code 的規則。
到了 VS Code 版本 1.85(大約是 2023 年底，撰文時版本號已經來到了 1.1百多)，增加了「拖曳獨立視窗 (Floating Windows)」的新特性。使用者只要用滑鼠按住那個標籤頁，往 VS Code 視窗外面的系統桌面上一拉(或是在 tab 上右鍵選擇在新視窗開啟)，它就會變成一個獨立浮動的作業系統視窗了。
但必須套件作者把功能實作在 Webview Panel（剛剛第6點介紹的，佔據一個標籤頁的模式），才能達到這種效果和使用方式。功能做在側邊欄的話，沒辦法獨立拉出去。
拖曳後資料消失
問題還不只這些，在 VS Code 中，如果使用者將 Webview 分頁拖拉到另一個分割區，或完全獨立的新視窗時，會發現原本在 Webview 裡操作的狀態（例如使用者剛剛塗鴉的畫面、輸入一半的表單）可能會瞬間不見！
這是因為視窗或分割區改變時，VS Code 底層為了重新渲染，會把 Webview 的 iframe 徹底銷毀並在新的位置重建。就算在建立 Webview 時加上了 { retainContextWhenHidden: true }，這個屬性也只能保證「切換到別的分頁再切回來」時不被銷毀，無法保護「跨越視窗」的重建行為。
開發者必須透過監聽 panel.onDidChangeViewState 事件，當發現面版重新變為可見狀態時，主動把暫存在 Extension Host 記憶體裡的資料重新塞回 Webview 裡。
因為我這個工具中，需要這樣操作的資料只有「圖片」，圖片可以暫存並轉成 Base64 字串，要把圖片資料重送回去還算簡單。
如果開發的是一個極其複雜的互動式儀表板（例如有幾十個 Filter、分頁、展開的樹狀圖）或表單，要在重建時把所有資料跟 UI 狀態完美還原，可能會寫到讓人懷疑人生。
常駐型應用程式
例如想做個語音轉錄之類的工具，收到電腦上有人按指定快速鍵，馬上就原神啟動~~開始聽寫，然後程式自動在 VS Code 裡面把草稿打好，等著人類去修改? VS Code 擴充套件沒辦法自己常駐系統在背景跑，只能自己想辦法做到類似笑果。
首先要先知道，VS Code 擴充套件有其他指令式的啟動方法:
vscode://user.blog-user-today-editor/xxx，經由套件 package.json 中的publisher和name的值來拼接，然後用vscode.window.registerUriHandler註冊一個名稱。code --command blog-user-today-editor.xxx，在 package.json 的contributes的commands內註冊好名稱，還有在extension.ts綁定邏輯程式，這邊設定的東西也會出現在剛剛第 8 點的 Command Palette 清單內。
然後在電腦 os 的 node.js 跑一支程式，監聽系統快速鍵，把資料傳給 VS Code 擴充套件。也可以用 AutoHotkey 之類的工具，把剛剛的指令綁在快速鍵上。
也許直接寫個 electron 應用程式可能比較快...
刻擴充套件的 UI，用原生的 TreeView 跟用 Webview 的差異
本套件是使用 Webview 來刻擴充套件的 UI，有些時候覺得效能不夠好。
其實還有另一種刻擴充套件 UI 的方式，就是用原生 TreeView，開發邏輯與外觀呈現有著天壤之別：
HTML Webview (自由奔放但肥大)
本質：就是一個跑在 iframe 裡的微型瀏覽器。
外觀：可以隨心所欲寫 HTML, CSS 甚至套用 Vue/React，做出任何想得到的酷炫按鈕跟動畫。
缺點：吃資源、記憶體佔用高、載入慢。而且需要自己手動發送 postMessage 才能跟 VS Code 擴充主程式 (Extension Host) 溝通。
原生 TreeView (極度輕量但死板)：
本質：VS Code 原生的 UI 元件。就像 VS Code 左側常見的「檔案總管」或「原始碼控制」那樣的樹狀列表。
外觀表現：完全不能寫 HTML 或 CSS。只能透過 VS Code 提供的 API (TypeScript) 去定義「這裡有幾個節點」、「這個節點的文字是什麼」、「旁邊要放什麼原生的 Icon」。
優點：極度省資源、啟動瞬間完成。它甚至無法放普通的輸入框 (input) 或自訂大按鈕 (button)，只能依賴 VS Code 原生的行為（如點擊節點觸發指令、點選單按鈕等）。
以下做一個語法範例對比，同樣做一個「輸入名稱、點按鈕就打 API」的功能：
範例：使用 Webview 的方式 (前端發送)
Webview 的寫法就像平常寫前端網頁，UI 是畫出來的，並使用標準的 fetch API（需注意可能會遇到 CORS 跨網域阻擋問題）：
<!-- Webview 中的 HTML -->
<input type="text" id="nameInput" placeholder="請輸入名稱" />
<button id="submitBtn">送出名稱並呼叫 API</button>
<div id="result" style="margin-top: 10px; color: var(--vscode-editor-foreground);"></div>
<script>
const vscode = acquireVsCodeApi();
document.getElementById('submitBtn').addEventListener('click', async () => {
const val = document.getElementById('nameInput').value.trim();
const resultDiv = document.getElementById('result');
if (!val) {
resultDiv.innerText = "請先輸入名稱！";
return;
}
resultDiv.innerText = "⏳ 載入中...";
try {
// 在前端 Webview 直接發送 Ajax (fetch) 請求
const response = await fetch('https://api.example.com/submit', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ name: val })
});
if (!response.ok) {
throw new Error(`伺服器錯誤 (HTTP ${response.status})`);
}
const data = await response.json();
resultDiv.innerText = `✅ 成功：伺服器回傳 ${data.message}`;
// (選擇性) 將成功結果回報給 Extension Host 進行後續檔案處理
vscode.postMessage({ command: 'apiSuccess', result: data });
} catch (error) {
// 例外錯誤處理
resultDiv.innerText = `❌ 發生錯誤: ${error.message}`;
console.error('API 請求失敗:', error);
}
});
</script>
使用原生 TreeView 與 VS Code API (後端 Extension Host 發送)
TreeView 裡面無法放入 <input>。如果需要使用者輸入文字，必須呼叫 VS Code 頂部的「中央浮動輸入框」。由於是由 Extension Host (Node.js 環境) 發起網路連線，最大的好處是完全不會有 CORS 跨網域限制。
// 在 extension.ts 主程式中
// 1. 建立一個按鈕指令 (綁定在 TreeView 節點或標題列上)
vscode.commands.registerCommand('myExtension.askNameAndFetch', async () => {
// 2. 呼叫「原生輸入對話框」 (它會從 VS Code 畫面上方彈出來)
const userInput = await vscode.window.showInputBox({
prompt: '請輸入要送出的名稱',
placeHolder: '例如: 我的新產品'
});
if (!userInput || userInput.trim() === '') {
return; // 使用者按下了取消對話框或沒輸入內容
}
// 3. 貼心的體驗：在 VS Code 的右下角顯示帶著轉圈圈的進度提示
vscode.window.withProgress({
location: vscode.ProgressLocation.Notification,
title: "正在發送請求到伺服器...",
cancellable: false
}, async (progress) => {
try {
// 在 Node.js 擴充主環境 (Extension Host) 發送 API 請求 (最新版 Node 支援原生 fetch，若是舊環境可以使用 axios)
const response = await fetch('https://api.example.com/submit', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ name: userInput })
});
if (!response.ok) {
throw new Error(`伺服器回應異常 (HTTP ${response.status})`);
}
const data = await response.json();
// 成功：跳出標準的右下角綠色打勾提示視窗
vscode.window.showInformationMessage(`✅ 成功：伺服器回傳 ${data.message}`);
} catch (error: any) {
// 例外錯誤處理：跳出標準的右下角紅色錯誤提示視窗
vscode.window.showErrorMessage(`❌ API 請求失敗: ${error.message}`);
console.error('連線出錯:', error);
}
});
});
如果套件需要提供豐富的表單、圖表、拖曳功能，必須使用 Webview，但要注意跨網域存取的問題。
但如果套件只是列出一堆指令清單，點擊後觸發擴充主程式執行 API 請求，那請毫不猶豫地選擇 TreeView 加上 showInputBox 與 withProgress 等原生 API，這會讓的擴充套件完美融入編輯器，並且避開瀏覽器諸多煩雜的限制！
直接嵌入外部網頁的挑戰 (Webview iframe)
文章開始有提到，我本來有一個基本的網頁介面用來上傳圖片，還有一些後端網頁程式用來接收 VS Code 傳送的資料，然後很多部分又說到 VSC 套件的機制某方面來說也是在顯示網頁，那乾脆把原本的網頁 URL 直接塞到 VS Code 裡面不就好了?
反正又不是沒做過那種網頁程式，然後要專門拿去塞在手機 APP 裡面用的，這樣 iOS 跟 Android 的工程師就不用再刻介面刻老半天。
但事情絕對沒有這麼簡單，直接在 VS Code 擴充套件塞入複雜的外部網頁(尤其是帶有登入機制的網頁程式)，會碰到一連串的問題：
要怎麼直接塞網頁
去翻找 VS Code 的 Webview API 文件，會發現 vscode.WebviewPanel 創建出來的 webview，根本沒有提供類似 src 或 url 的屬性讓指定外部網址直接載入。
既然它要我們自己生出畫面，那如果我學寫爬蟲那樣，透過 fetch 把外部網頁的整包 HTML 抓下來，再當成字串顯示出來呢？
這會是一場災難。因為如果硬塞外部網頁的原始碼進入 Webview，網頁內所有的相對路徑（如 <link href="/css/style.css"> 或 <img src="/images/logo.png">）全部都會找不到目標來源而失效破圖。再加上前面提過 Webview 沙盒環境的極度嚴格限制，那個外部網站絕對會發生滿滿的載入錯誤。
既然 VS Code 規定它的 Webview 是用來塞 HTML 原始碼的，那麼最直覺的解法，就是塞入 iframe 的 HTML 字串：
<iframe src="https://我的網址/" style="width:100%; height:100%; border:none;"></iframe>
嘗試在 VS Code 套件裡面做出一個類似網頁瀏覽器的東西，如下圖:
然後還做了上一頁、下一頁、重新整理、網址列，基本除錯資訊視窗。
網站本身有拒絕外部載入的機制
第一個會遇到的通常是白畫面。為了防止各種網頁資安攻擊，現代主流網站通常都會加上 X-Frame-Options: SAMEORIGIN 或是嚴格的 CSP Header。這些東西除了可以避免自己的網站隨便被人嵌入到其他網頁中，還有讓某些攻擊手法武功全廢。
但在本文的情境中(把網頁的一些寫好的圖片管理程式 URL 直接搬到 VS Code 裡面)，會無情地指示瀏覽器：「這個網頁不允許被放在別的網域的 iframe 裡面」，因此直接被 VS Code 內建的 Chromium 核心給阻擋下來。
這些問題在以前把網頁直接塞進 Electron 時就碰過，有些問題大同小異，知識點是共通的，但 VS Code 又是另一回事。
例如上面的偽瀏覽器範例，要多做一層 proxy，想辦法先檢查輸入的網址有沒有加 CSP 或各種安全標頭，不然就是白畫面一張，根本不知道出了什麼問題。
CORS 跨來源資源共用：沒有固定網址的痛
退一步說，就算我們放棄 iframe，真的跑去改前端程式碼，打算在 Webview 裡面用 fetch 或 axios 去敲外部的 API，馬上又會撞上 CORS 問題。
當我們在瀏覽器寫前端，要發送跨網域請求時，後端（例如 PHP 寫的 API）必須在 Header 加上 Access-Control-Allow-Origin: https://允許的網址.com 來放行。
但 VS Code 的 Webview 根本沒有一個正常的、固定的網址！
它的 Origin 會是一長串隨著 VS Code 版本或環境隨機生成的內部機制網址(像是 vscode-webview://1234abcd...)。後端程式根本無從得知要把哪個網址加進允許名單。
如果為了解決這個報錯，後端直接設定 Access-Control-Allow-Origin: * 來對全世界敞開大門... 那等於是把伺服器的資安防護直接拆掉，尤其是有帶登入權限的後台 API，這樣做無疑是自殺行為。
Service Worker 噴錯：InvalidStateError
假設真的把伺服器的一堆安全標頭拿掉成功載入了，馬上會遇到其他報錯，例如：
載入 Web 檢視時發生錯誤: Error: Could not register service worker: InvalidStateError: Failed to register a ServiceWorker: The document is in an invalid state.
現在許多現代化網站都會註冊 Service Worker 來實作離線快取/推播/iOS PWA等功能。
然而，VS Code 的 Webview 運行在一個極度受限且隔離的特殊環境，在這種動態沙盒環境下，底層的 Chromium 引擎會將 iframe 的文件狀態判定為 invalid state，嚴格禁止註冊 Service Worker。
被閹割的 iframe sandbox
為了讓外部指令碼能跑，可能會在 iframe 加上 sandbox="allow-scripts allow-same-origin allow-forms"。但 Webview 本身的權限已經被外層 VS Code 削弱過一次，即使在 iframe 開了權限，裡面運行的外部網站依然無法像在真正瀏覽器分頁中那樣自由操作 Cookie、LocalStorage 或 IndexedDB 等持久化儲存。
這會導致登入狀態無法維持，或是各種現代前端 framework 直接罷工。
令人困擾的 retainContextWhenHidden
當好不容易克服萬難把網頁塞進去了，使用者操作這個「網頁」操作到一半，這時如果點了旁邊的其他 editor tab，Webview 面板被切換到背景... 等再切回來時，畫面可能會重新載入，剛剛打的字全沒了！
雖然 VS Code 提供了 retainContextWhenHidden: true 的選項來解決這個問題，但官方文件強烈警告：這會消耗大量的記憶體。
Although retainContextWhenHidden may be appealing, keep in mind that this has high memory overhead and should only be used when other persistence techniques will not work.
來源:Extension API - retainContextWhenHidden
因為這等同於在背景維持一個完整的 Chromium 渲染行程不被釋放。如果是塞入一個前端肥大的網頁，多開幾個就會讓 VS Code 變得很卡。(本文其他段落有研究怎麼用 panel.onDidChangeViewState 設法把資料塞回去)
資源載入限制 localResourceRoots
有時候為了效能或突破限制，可能會想把外部網站打包一部分到本機執行。但 Webview 預設禁止讀取本機電腦上的檔案。
必須在建立 Webview 時嚴格設定 localResourceRoots 陣列，精確指定只有套件目錄下的某些資料夾（例如 /dist/ 或 /media/）允許被載入，否則連一張本機圖片都顯示不出來。
視窗顯示位置 ViewColumn
建立 Webview 時必須指定 ViewColumn。如果寫死成 ViewColumn.One，它永遠會搶佔最左邊的分割區。
如果是 ViewColumn.Active，則會在使用者目前的焦點區域開啟。沒設定好常常會破壞使用者的 editor tab 佈局，或者視窗不知道彈到哪個已經沒在看的分割螢幕去了。
合理的開發架構
因為上述種種安全性跟架構限制，在 VS Code 套件直接用 iframe 塞入複雜外部網站，大概就跟拿紙吸管&鋼筆去吃拉麵一樣，然後還要說這原子筆跟吸管設計有問題，害我們不能好好吃麵，然後研究原子筆跟吸管要怎麼設計才能順利吃拉麵......為什麼不好好拿筷子湯匙吃麵呢?
在 VS Code 擴充套件的世界，比較合理的開發邏輯:
1.採用 API 優先 (API-First) 的開發架構
如果想要讓 VSC 擴充套件跟現有網站一些前端程式，共用同一支後端程式邏輯?
網站程式一開始就必須設計成純粹提供 JSON 資料的 HTTP RESTful API 或其他 API 開發架構。不能只是傳統 MVC 或 template engine 那種藕斷絲連的設計。
後端 API 必須是無狀態的(Stateless)，不能過度依賴瀏覽器專屬的 Cookie Session。這樣才能讓 VS Code 的 Extension Host 也能像個平等的客戶端一樣，直接用某種驗證方式，呼叫 API 執行動作。
2.使用前面提到的 Message Passing 架構
乖乖用 treeview 或 webview 或 command palette 寫原生的 UI，讓 VS Code 擴充套件只負責單純的 UI 呈現，然後透過 postMessage 呼叫 Extension Host，由後端去跟外部伺服器發送 API 請求拿資料，再傳回 UI。沒事不要挑戰直接把寫好的網頁直接 iframe 塞進去。
VS Code Webview 跟一般網頁的不同
上面都在說 Extension 開發邏輯的不同，那如果就鐵了心要在 Webview 裡面大寫特寫 HTML/JS/CSS 呢？
請注意，雖然 Webview 裡面就像一個小瀏覽器，但它為了確保編輯器的穩定性與安全性，被閹割了許多原生的瀏覽器行為。如果用常規寫網頁前端、Node.js 後端的思維去寫 Webview，保證會踩雷：
CSS 支援度與預設樣式
Webview 支援絕大部分現代 CSS，版本號並沒有跟 Chrome stable 差太多，但 VS Code 預設就會在 Webview 注入一堆基礎樣式（例如 body 預設就沒有外距，字體已被強制設定為等寬或跟隨編輯器的主題字體）。
html 與 body 的 height 行為可能跟一般瀏覽器有落差，不要輕而易舉地依賴全螢幕 vh 或全版 fixed 屬性，特別是在多層嵌套的 Sidebar Webview 內，很容易會有捲軸出錯或內容被切斷的問題。
恐怖的對話框：alert(), confirm(), prompt()
在一般的 JavaScript 裡面，可能習慣呼叫 alert('哈囉')。但在 Webview 裡面呼叫傳統的原生彈跳視窗是無效的，甚至可能會拋出錯誤並靜默失敗！
VS Code 嚴格禁止 Webview 彈出這種會強行阻塞執行緒 (Thread-blocking) 的系統對話框。如需提示使用者什麼事情出錯了，請一律透過
postMessage，請後端 Extension Host 呼叫原生的 vscode.window.showInformationMessage 這種非阻塞 toast style 通知。
好笑的問題又來了，我用的是比例 21:9 的寬螢幕，一開始用 vscode.window.showInformationMessage 還以為程式壞了，怎麼按都沒反應，因為眼睛盯著左邊側邊欄，而那個通知則是小小默默的在視窗最右邊...。
如果希望警告能像真正的 Dialog 一樣強迫使用者注意到並阻斷操作，可以在呼叫時傳入 { modal: true } 參數，它就會從視窗正中央彈出來，迫使使用者必須點擊按鈕才能關閉：
// 在 Extension Host (後端) 中執行：
vscode.window.showInformationMessage('這是一個會出現在畫面正中央的對話框！', { modal: true });
如果想要 VSC 擴充套件彈出 Windows 10/11 Action Center 的系統級原生通知，VS Code 原生的 API 沒提供，要另外用第三方套件，或想辦法生成 Powershell 指令再丟給 child_process 去執行。
令人混淆又驚豔的原生元件體驗
難免會遇到需要讓使用者選取顏色的情境，例如其中一個功能是在圖片上畫色塊，那令人好奇的事又來了，它會顯示 os 層級的調色盤，還是 chromium 的那種調色盤?
在 Webview 裡直接使用原生的 HTML5 <input type="color">，因為 VS Code 底層是基於 Electron（也就是 Chromium 核心），所以彈出來的並不是傳統小畫家或 Office 詳細色彩裡的那種 Windows 經典原生選色器，而是 Google Chrome / Chromium 內建的那個現代風格調色盤。
這個細節展示了 VS Code (Electron) 在處理底層 HTML 標籤時的有趣現象：很多地方就像開發網頁程式，繼承了 Chrome 的許多預設行為，但有些地方又不是那麼回事。
取得使用者電腦硬體與系統資訊
既然我們知道 VS Code 的 Extension Host 是一個滿血的 Node.js 環境，所以我們完全有能力取得使用者電腦的底層資訊，這是一般跑在瀏覽器的網頁、web app絕對做不到的。
甚至可以取得使用者的環境變數，然後把字串全部傳到別的地方去。
基本系統資訊
在 extension.ts (後端) 中，可以直接 import * as os from 'os';，它能提供許多系統資訊：
- 作業系統平台：
process.platform結果會印出例如'win32'(Windows)、'darwin'(macOS) 還是'linux'。 - 電腦名稱：
os.hostname()可以取得電腦名稱 (例如 USER-PC)。 - CPU 架構與型號：
os.arch()(如 x64, arm64)，以及os.cpus()會回傳一個陣列，裡面詳細列出每一顆 CPU 核心的型號名稱 (如 "Intel(R) Core(TM) i7...") 和運作時脈。 - 記憶體資訊：
os.totalmem()(總 RAM) 和os.freemem()(可用 RAM)。 - 網卡 MAC Address：
os.networkInterfaces()會回傳所有網卡的詳細資訊，包含內網 IP 和 MAC 位址 (屬性為mac)。
比較特別的是 os 模組無法直接撈到 GPU 的型號，如果需要知道裝置的顯示卡，可以利用 child_process 呼叫系統指令，例如在 Windows 上，可以用 child_process.exec 去執行 WMI 指令 (例如 wmic path win32_VideoController get name) 來抓取顯卡名稱。在 Mac 上可以呼叫 system_profiler SPDisplaysDataType。或是使用 systeminformation 之類的第三方套件。
var cp = require('child_process');
var os = require('os');
var platform = os.platform();
var command = '';
if (platform === 'win32') {
command = 'wmic path win32_VideoController get name';
}
else if (platform === 'darwin') {
command = 'system_profiler SPDisplaysDataType | grep "Chipset Model"';
}
else if (platform === 'linux') {
command = 'lspci | grep VGA';
}
環境變數 (Environment Variables) 的風險
除了電腦名稱和網卡 MAC 位址，更危險的是系統的環境變數 (process.env)。有些開發者如果是直接把應用程式佈署在 OS，並習慣將重要的開發金鑰（例如 AWS Access Key、Claude API Key、OpenAI Key 等）直接設定在作業系統的全域環境變數中，方便各個專案共用? 那有福了。
這代表任何安裝在 VS Code 內的擴充套件，只要具備基礎的 Node.js 執行權限（通常都有），都能在背景輕易讀取電腦上的所有環境變數！
如果安裝到了來路不明的惡意套件，它完全可以默默地將 process.env 中的金鑰透過 AJAX fetch() 或 https 傳送到套件作者的伺服器上。
因此：
- 不要輕易安裝不知名、下載量極低的擴充套件、來路不明的 vsix 檔案。
- 對於極度敏感的金鑰，建議盡量寫在專案目錄下的
.env檔案中，並加入.gitignore，而不是設定在作業系統的「全域」環境變數內。（一般套件不會隨便去讀取、解析每個專案的.env，但真要撈的話卻是輕而易舉的事）。 - 若擴充套件本身需要儲存使用者的金鑰，請務必且強烈建議使用 VS Code 官方提供的 SecretStorage API (
context.secrets) 來存取，它會將金鑰加密儲存在作業系統的安全儲存區（如 Windows 認證管理員、macOS 鑰匙圈）中，大幅降低洩漏風險。
實作上，整個模式基本就是 Extension Host 裡用 os 模組，抓好電腦名稱或網卡 MAC，執行某些指令，再透過 postMessage 送到 Webview 印出來。
因為這個擴充套件只是個人自用，所以沒有走審核上架流程，所以不知道例如做一些偷幹資料的功能，但把程式碼混淆，會不會被退件拒絕上架。
不要用 User-Agent 字串判斷平台
如果依賴 navigator.userAgent 來判斷使用者現在是 Windows 還是 Mac，在 Webview 裡拿到這串字串有時候會混雜了 Electron、Code 等奇怪的自訂標記，而且不一定能精確反映底層的真實 OS 狀況。
真要判斷 OS 環境，例如用來顯示不同的鍵盤快速鍵或指令之類的，應該在 Node.js 主程式用 process.platform (會是 win32 之類的)，透過變數丟給前端 Webview 使用才最準確。
另外還有一個 vscode.env，它並不是用來判斷作業系統（裡面沒有 os 屬性），而是用來取得 VS Code 編輯器本身的環境狀態。
直接把它整包印出來會失敗（或是印不完整），因為裡面包含了像 clipboard（剪貼簿操作）或 openExternal（開啟外部網址）這種「函數與複雜物件」。但如果去讀取它裡面的純文字/布林值屬性，會發現很多實用的寶藏：
appName: 編輯器名稱 (例如 "Visual Studio Code"、"Cursor"、"Antigravity")language: 使用者的介面語系 (例如 "zh-tw")machineId: 綁定這台電腦的唯一識別碼remoteName: 如果使用者是用 Remote SSH 或 Codespaces 連線，這裡會有遠端機器的名稱；如果是本機開發則是undefined。uiKind: 看現在是跑在桌面版 (Desktop) 還是網頁版 (Web, 例如 vscode.dev) 編輯器中。
擴充套件簡介頁面 (Marketplace Intro) 與 Icon 設定
當擴充套件打包發布，或是在 VS Code 側邊欄點選套件時，都會看到一個「擴充套件簡介頁面 (Extension Details)」(如下圖)。
若要讓這個介面看起來專業且功能介紹完整，有幾個關鍵的設定檔案必須同步更新：
README.md (詳細介紹與圖文)
套件的首頁 (Details Tab) 內容，完全來自專案根目錄下的 README.md。VS Code 會自動將這份 Markdown 檔案渲染成 HTML 顯示在簡介頁面。
每當新增功能，一定要回頭更新這份 README。這能確保使用者了解最新版本有什麼新亮點。
CHANGELOG.md (版本更新紀錄頁籤)
除了首頁的 Details 頁面，VS Code 的套件介紹其實還內建了 Changelog 這個專屬頁籤。
VS Code 不是自己去撈 GitHub repo 的 commit 紀錄，而是非常單純地讀取在專案根目錄底下的 CHANGELOG.md 檔案。
如果將更新記錄全寫在 README.md 裡，使用者在 Changelog 頁籤只會看到一片空白。最佳實務是將詳細的功能介紹留在 README，並且將每個版本的具體修正 (Added/Fixed/Changed) 規矩地寫在 CHANGELOG.md 裡面。打包 .vsix 時，這兩個檔案都會自動被包含進去。
package.json 的 icon 設定
螢幕空間有限，所以一個功能在介面上通常只會看到一顆 icon，一個套件裡面有 N 處要設定，如果套件中途換 icon，總會發現有遺漏沒改到的。
預設的擴充套件介面在左側 Activity Bar 用了 $(file-media) 或 $(gear) 這類的 VS Code 內建的 Codicons 圖標，它在側邊欄會完美顯示。
但是在擴充套件詳細介面（或 Marketplace 商城）上，必須提供一張圖片檔:
- 格式要求：必須是一張解析度至少為
128x128或256x256以上的圖片 (支援 PNG 或 SVG)。 - 設定方式：在根目錄建立
images/icon.png後，於package.json第一層加上一筆"icon": "images/icon.png"。 - 設計建議：為了與 Activity Bar 圖示保持一致體驗，建議將原本的線條 Icon 加上單色背景，以免毫無一致性，使用者難認出這是什麼套件。
測試擴充套件
我每次改完程式碼，是不是都要重新打包成 .vsix 檔案，再反覆安裝、解除安裝來測試？
開發途中需要用一些莫名其妙的方法，例如每次要先把穩定版本移除，才能測試開發中的版本?
答案是：完全不用！
微軟提供了一套極度親切的 hot reload 機制，我們在開發階段，只需要打開 vscode 套件的專案資料夾，按下鍵盤 F5 即可，這會自動編譯，並自動開啟一個新的 VS Code 視窗，可以即時測試擴充套件。
當套件程式碼有修改，也不需要重新打包成 .vsix 檔案，再反覆安裝、解除安裝來測試。只要按下上圖中的 reload 按鈕，變更就會立刻生效！
這個新視窗通常會顯示 Extension Development Host，只有這個視窗可以用到新版本的套件，其他視窗都還是本來安裝的版本。這樣看起來不會弄髒原本真正工作用的 VS Code 環境。
印出除錯資訊
寫網頁前端時，有時候會用 console.log 來印出訊息除錯，但在 VS Code 擴充套件的世界裡，前後端的除錯訊息會出現在不同的地方：
如果在 Webview 的 HTML/JS 裡寫了 console.log('前端訊息')，它不會出現在 VS Code 預設的終端機或輸出面板裡。
我們必須打開專屬於 Webview 的開發者工具：按下 Ctrl+Shift+P (或 Cmd+Shift+P) 叫出命令選擇區，輸入並執行 Developer: Open Webview Developer Tools，接著會彈出一個和 Chrome F12 一模一樣的 DevTools，就能在裡面的 Console 看到熟悉的 console.log 輸出了。
如果是在 extension.ts 等 Node.js 主程式中寫了 console.log('後端訊息')：
- 在開發測試階段 (按 F5 執行時)：訊息會印在原本撰寫程式的那個 VS Code 視窗底部的「除錯主控台 (Debug Console)」面板中。
- 正式的日誌輸出 (無需要 F5 也能查閱)：建議使用 VS Code 提供的 Output Channel API。
// 建立一個專屬的輸出通道
const outputChannel = vscode.window.createOutputChannel("XXXXX Log");
// 寫入訊息
outputChannel.appendLine("這是一筆除錯日誌");
// (選擇性) 強制讓面板顯示並切換到我們的通道
// outputChannel.show();
這樣使用者就可以從底部面板的「輸出 (Output)」頁籤，並從下拉選單找到「XXXXX Log」來查看套件運作的日誌了。
產生安裝檔案 (vsce package)
只有覺得開發已經告一段落，要把這個版本永久停留在我的作業系統上，或者是我要把這個套件傳給其他電腦安裝時，才需要打包。
- 打包指令：執行
npx vsce package。 - 這個指令會讀取的
package.json(包含裡面的version,icon等資訊) 與README.md，然後將所有原始碼壓扁打包成一個.vsix檔案（例如my-extension-0.8.0.vsix）。 - 最後才透過 VS Code 擴充套件面板右上角的「從 VSIX 安裝 (Install from VSIX...)」把這個成果真正部署到電腦中。
不要以為能正常建置就沒事，也有可能在安裝或執行時報錯，例如前面所講的跨平台問題，進入漫長的 debug 地獄。
結語
這算是一個 vibe coding 實驗性質的玩意，網頁設計與程式的技能可以拿來做很多事，不知道為什麼有些人總覺得只能拿來做形象網站、購物網站?
就像幾年前 Flash Player 即將停止支援，各大網頁瀏覽器在整人的時候，本部落格也試玩過一個 Electron 桌面應用程式，Electron 實戰：讓 Mac 玩開心水族箱不用再每次按允許 Flash ，把開心水族箱的 Flash 網頁搬到 PC 桌面應用程式。
以前總覺得開發桌面應用程式的擴充套件門檻很高，還要學很多底層的 API?
但實際動手嘗試後發現，除了傳統的開發方式，如果站在巨人的肩膀上，在 VS Code 裡面執行，只要釐清了 Webview（前端 UI）與 Extension Host（後端 Node.js）之間的通訊機制與沙盒權限邊界，剩下的開發體驗其實就跟寫一般的全端網頁應用程式差不多。
把寫作、修圖、圖檔上傳、甚至終端機指令操作，全部收斂回常常盯著看的 VS Code 介面中，大幅減少了在不同應用程式與瀏覽器分頁間來回切換的心智消耗，讓維護部落格這件事變得流暢純粹了不少。
雖然這個套件只是為了解決自己的痛點而生，有些機制也沒有做得很嚴謹，但能隨心所欲地打造出最符合自己工作流的工具，不被現成平台的框架侷限，這大概就是浪漫與樂趣吧。
如果平時開發或寫作上也有一些繁瑣的重複性操作，不妨也試著寫一個專屬自己的 VS Code 擴充套件試試看！