DeskPad 開源虛擬顯示器，視訊會議分享不再播出整個桌面

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

DeskPad 值得裝，對象也很明確：視訊會議多、桌面又亂的 Mac 使用者。它是開發者 Bastian Andelefski 一人維護的開源小工具，整支程式 1.1MB，啟動之後 macOS 會多出一台名叫 DeskPad Display 的螢幕，照它的設計，把要分享的視窗拖到那台螢幕上，會議軟體就只分享那一台，通知、訊息預覽、桌面上散落的檔案全部留在主畫面。把它的安裝包抓下來驗完簽章、再翻完整個原始碼之後，我的判斷是：可以裝，它對你畫面的保障是沙盒結構給的，不靠開發者自律；同時你該知道它站在 macOS 沒有公開文件的介面上，安裝包從 2024 年 10 月之後就沒有再出過新版。值得裝與該小心，兩件事都成立。

分享整個螢幕等於交出整個桌面，虛擬顯示器是第三條路

視訊會議軟體給你的分享選項通常只有兩種，而兩種都有代價。分享單一視窗，切換應用程式時對方會看到黑畫面或卡在最後一個畫面，工作流程一被打斷就得重新分享；分享整個螢幕，桌面上的一切就全部播出去了，包含同事傳來的訊息預覽、跳出來的行事曆提醒、瀏覽器分頁標題，甚至是背景自動啟動的其他工具。遠端會議看過別人螢幕上跳出私人訊息的人，都明白這種事故不需要發生第二次。

虛擬顯示器給出第三條路：在系統裡多插一台不存在的螢幕，把它當作分享專用的工作區。視窗拖過去之後，你照常在自己的主螢幕上做事，會議那端看到的永遠只有虛擬螢幕上的內容。macOS 一直沒有把對應的開關放進系統設定（顯示器設定裡的加號只認得 AirPlay 與 Sidecar），Apple 官方的「Mac Virtual Display」則是給 Vision Pro 用的配對功能，跟一般開會情境無關。想在自己的 Mac 上長出一台虛擬螢幕，實際的選項都在第三方：閉源路線的主要替代品是 BetterDisplay，而 DeskPad 補的是另一個極端：免費、開源（MIT 授權）、Homebrew 一行指令就裝好，除此之外什麼都沒有。

一台假螢幕怎麼被造出來：偽裝成外接顯示器，再把畫面搬進自己的視窗

DeskPad 的核心魔法不到一百行 Swift。翻它的原始碼會看到，它向 macOS 註冊顯示器時用的描述資料，跟一台真實外接螢幕沒有兩樣：名稱叫 DeskPad Display，帶著自己的產品編號 0x1234、廠商編號 0x3456 與序號 0x0001，只是這些編號都是寫死的假值。README 對這台螢幕的說法是：啟動 DeskPad 等於插上一台螢幕，macOS 會自己把視窗安排到原本的位置，它會出現在系統設定的顯示器清單裡，解析度也從系統設定調整。

造出螢幕只是上半場，接下來是鏡射。虛擬螢幕本身沒有實體面板，DeskPad 於是用系統的畫面串流介面，把虛擬螢幕上的每一個畫面抓下來，畫進自己那個 App 視窗裡。你在自己的主螢幕上看著 App 視窗，就知道對方此刻看到什麼。串流參數裡連滑鼠游標都設成要顯示，並且以每 0.25 秒一次的頻率偵測游標落在哪一台螢幕：當你把游標移進虛擬螢幕的範圍，視窗標題列會轉成藍色、視窗自動浮到最上層，提醒你「現在人在虛擬螢幕裡」；反過來，直接在視窗上點一下，系統會把游標傳送到虛擬螢幕上對應的位置。這些細節對使用體驗的影響很大，因為你等於同時操作兩台螢幕，方向感不能亂。

整支程式只有 1.1MB，原因是它幾乎什麼都沒捆：連結庫清單裡只有 AppKit、CoreGraphics 這些系統框架，狀態管理用的是一個輕量的開源套件，沒有任何網路、媒體或影像處理的第三方依賴。小，是因為真正困難的工作都交給了系統本身。

Pin

原始碼裡有 15 種解析度，你裝到的版本只有 11 種

這是翻原始碼與抓安裝包對照後才會發現的落差。目前 main 分支登錄了 15 種顯示模式：32:9 的 5120×1440、21:9 的三種（5120×2160、3840×1600、3440×1440）、16:9 的六種（3840×2160 到 1280×720）、16:10 的五種（2560×1600 到 1280×800）。但 Homebrew 與 GitHub 發布頁提供的安裝包都停在 v1.3.2，那個版本的原始碼裡只有 11 種模式，最寬 3840，超寬比例全部缺席。

落差怎麼來的：超寬螢幕支援是一個 2024 年 2 月就提出的合併請求，在倉庫裡躺了超過兩年，2026 年 2 月 28 日才被作者併進 main，而那天也是整個專案最近一次程式碼提交，併完之後沒有跟著打出任何新版安裝包。也就是說，原始碼看得到的功能，不等於你今天裝得到；想用 21:9 或 32:9 的話，只有自己抓原始碼編譯一條路，MIT 授權允許你這麼做。

Pin

沙盒、零網路框架、開發者簽章：它能看你的虛擬螢幕，但連不出去

會議工具要求權限時，最該問的問題是它有沒有能力把你的畫面送出去。DeskPad 在這一點上給的答案相當乾淨，而且不是口頭承諾。把 v1.3.2 安裝包抓下來檢查，幾個客觀證據指向同一個結論。它是 App Sandbox 應用，權限聲明裡只有一條允許讀你主動選擇的檔案，加上一條向系統註冊虛擬顯示器的服務查詢；連結庫清單裡找不到任何網路框架，程式在結構上就沒有對外連線的零件；就連 Homebrew 的解除安裝定義，清理的也只是它沙盒容器裡的兩個資料夾，沒有其他落點。安裝包另帶著開發者簽章與蘋果公證票證，簽章主體正是作者本人的 Developer ID 帳號。

這些檢查不難自己做。裝好後在終端機輸入兩行指令就能重現同樣的結論：

codesign -dv --verbose=2 /Applications/DeskPad.app
spctl --assess --type execute -vv /Applications/DeskPad.app

第一行攤開簽章主體與簽章時間，第二行讓 Gatekeeper 現場評估一次，看到 accepted 與 Notarized Developer ID 字樣，就代表這個安裝包通過蘋果的公證流程，沒有被中途調包。

換句話說，DeskPad 讀得到你的虛擬螢幕畫面（這是它鏡射顯示所必須的），但它沒有把畫面送往任何地方的通路。這種「架構上做不到」與「政策上答應不做」的差別，在隱私工具的挑選上是根本性的，前者不會因為一次改版或一次收購而失效。同一套檢驗標準，先前檢視線上 EXIF 檢視器時也用過：宣稱不上傳，要在程式碼層找到對應的結構證據才算數。

專案本身也經得起基本盤檢查：2022 年 4 月開始，GitHub 上近 7,900 顆星、178 次 fork，v1.3.2 安裝包在發布頁累積超過 4.2 萬次下載。一人專案的風險仍在（後面會談），但至少不是來路不明的封閉二進位檔。

Pin

第一次啟動會跟你要螢幕錄製權限，這是正常流程

DeskPad 啟動後可能會遇到一個看起來有點矛盾的詢問：要不要開放螢幕錄製權限（README 的措辭是 may need）。一個螢幕分享工具要求錄製權限，實際上正是它的工作原理所需：它要把虛擬螢幕上的畫面串流到自己的視窗裡，這個讀取畫面的動作在系統裡屬於螢幕錄製保護的範圍。授予之後重新啟動 App，虛擬螢幕的畫面才會真正顯示出來。

README 的疑難排解也坦白記了這一段：如果授權後 DeskPad 有出現但畫面不動，到系統設定的隱私權與安全性能裡，把 DeskPad 的權限取消再勾選一次，接著重新啟動 App。討論區裡另有幾則黑畫面或視窗不出現的案件，成因不一，權限重勾只是官方文件提供的第一個解法。系統門檻方面，安裝包標示的最低需求是 macOS 13（Ventura），Intel 與 Apple Silicon 的機器都支援，安裝包本身是雙架構通用格式。

闔上筆電就失效，還有幾個已知狀況

使用上的邊界，issue 追蹤器比 README 誠實。幾個值得裝之前就知道的：筆電若是闔上外接螢幕使用的蛤蜊殼模式，虛擬螢幕的行為會出問題，有人直接以「沒辦法在蛤蜊殼模式下使用」為題開了問題；在 Microsoft Teams 這類視訊軟體裡，某些視窗會蓋住虛擬螢幕上的游標，讓使用者點不到畫面；有人反映 1920×1080 模式下的畫面明顯延遲；而想要一次開兩台以上虛擬螢幕的人，目前也做不到，原始碼層一個 App 實例只建立一個虛擬顯示器，多開需求從 2024 年底掛在討論區至今仍沒有實作。

這些狀況沒有一個是致命的，但它們描出了工具的形狀：DeskPad 是為「單人、單機、開著筆電開會」的情境設計的，離開這個情境，體驗沒有保證。

macOS 每年大改版，都是私有 API 的一次考試

DeskPad 原始碼裡有一個檔名很說明一切的標頭檔：CGVirtualDisplayPrivate.h。內容是另一位開發者 Khaos Tian 在 2021 年逆向整理出來的系統私有介面宣告，DeskPad 直接引入使用，也就是蘋果從未寫進公開文件、也不對第三方承諾穩定性的那批功能。DeskPad 能用不到一百行程式碼造出虛擬螢幕，正是因為直接用了這批介面；代價則是蘋果任何一次系統改版都可能讓它失效，而且蘋果沒有義務提前通知。

這個風險不是理論。游標消失的問題其實 2024 年 2 月就有人反映過，macOS Sequoia 更新後又湧出一波，社群在 9 月下旬提交修復，作者 10 月 4 日併入並打包成 v1.3.2 發布，10 月下旬出現的同類案件，答案也是「更新到最新版就好了」。issue 追蹤器裡目前還看不到 macOS 26 的災情，但「沒有人反映」不等於「保證相容」，畢竟這支安裝包的年紀比新系統還大。想長期使用的人要有心理準備：作者近一年只整理了文件與合併一個舊請求，沒有新的發布節奏；好的一面是 MIT 授權讓任何人都能接手，已經有人把它的虛擬顯示器部分拆成獨立的 Swift 套件，接手的材料是齊全的。

同樣處理螢幕內容，它和錄影、鏡像工具的分工

TechMoon 先前介紹過幾個同樣與螢幕內容打交道、但任務不同的工具。要把自己畫面錄成影片的，RecordScreen.io 走瀏覽器錄影路線，錄完直接出檔；要把 Android 手機畫面投到電腦的，escrcpy 是開源的鏡像方案；要在 Mac 上跑另一套系統來測試軟體的，VirtualBuddy 用 Apple Silicon 的虛擬化能力開虛擬機。DeskPad 的位置剛好都不重疊：它不改變你的畫面內容，只決定哪些畫面被會議軟體看見。四種需求如果同時存在，它們是並列的關係，不是替代。

放進 /Applications 之前的取捨

適合的人：會議多、在乎畫面外流、桌面上有不便入鏡內容的 Mac 使用者，尤其是常態接外接螢幕、已經習慣多桌面工作的人，把虛擬螢幕當成分享專用桌面，幾乎零學習成本。安裝就兩條路：Homebrew 的 brew install --cask deskpad，或到 GitHub 發布頁抓安裝包，兩者拿到的是同一個 2024 年 10 月的 v1.3.2。

不適合的人也很清楚：需要超寬解析度而不願自己編譯的、想要多台虛擬螢幕的、以蛤蜊殼模式工作的，以及對「工具必須有活躍維護」有硬性要求的人。它是那種把一件小事做對、然後停格的工具：結構乾淨、授權開放、下載管道正經，但生命週期繫在一個人的業餘時間與蘋果的介面穩定性上。裝它，就是接受這兩個前提；驗證過簽章再裝，剩下的風險就只有系統改版這一種，而那種風險，到時候再處理也來得及。