題幹與適用場景
一個 SaaS 平台要載入第三方規則外掛。外掛可能由不同語言編寫，宿主希望在同一程序或輕量執行時中重用它們，同時只允許存取明確授予的時鐘、日誌和物件儲存介面。請解釋核心 WebAssembly 模組、Component Model、WIT、WASI 的關係，並給出版本、效能、安全和維運方案。
這道題考察跨語言執行時與安全邊界，不是背「接近原生速度」。WebAssembly 3.0 規範把核心 Wasm 定義為可驗證、沙箱化的虛擬指令集；Component Model 在其上增加型別化介面、組合和呼叫約定；WIT 描述介面，WASI 以 WIT 形式提供系統能力。核心答案必須區分「模組能執行」與「外掛能安全使用宿主能力」。
面試官考察點
強回答會從最小能力集合開始，先定義外掛需要的介面，再決定是否用 Component Model，而不是直接給每個外掛一個宿主程序。它應說明核心模組共享線性記憶體的限制、Component 透過型別化介面隔離、world 如何宣告 imports/exports，以及宿主如何拒絕未授權匯入。
還要看到現實權衡：沙箱不等於業務安全，宿主暴露的介面仍可能洩露資料；跨邊界傳遞大物件有複製和適配成本；Component Model 和 WASI 版本仍需鎖定執行時矩陣。面試準備資料通常把可移植性、隔離、介面設計和失敗恢復作為系統能力，而不是單一工具知識。
回答前需要釐清的問題
外掛信任與隔離目標
確認外掛是自家程式、合作夥伴程式還是完全不可信程式。若對手能逃逸宿主程序，單一 Wasm 沙箱可能不足，需要獨立程序、核心隔離或專用服務。也要問是否允許網路、檔案、隨機數和時間，因為每項都會擴大能力邊界。
呼叫模型與資料規模
確認呼叫是短同步規則、長任務還是串流處理。小型結構化值適合介面邊界；大檔案應透過受控控制代碼或宿主管理的物件傳遞，避免頻繁複製。延遲目標和併發量決定是否需要實例池、預熱和背壓。
版本與故障契約
確認外掛和宿主誰先升級、是否要同時支援舊介面、失敗能否重試以及副作用是否冪等。若外掛寫入外部系統，必須定義逾時後的未知結果、冪等鍵和稽核記錄。
30 秒回答框架
「我會把外掛視為只透過宣告介面互動的 Component。先用 WIT 定義最小 world，例如匯出 evaluate，只匯入日誌和受限物件讀取；宿主按能力清單實例化，不提供未宣告的匯入。WASI 只是標準化的一組系統介面，不等於自動擁有檔案或網路權限。核心 Wasm 模組解決可驗證執行，Component Model 解決跨語言型別和組合。版本化介面、限制資源和故障重試，再用越權、相容、效能和恢復測試證明安全邊界；若外掛完全不可信或需要大量共享狀態，我會選擇獨立服務。」
分步驟深入解答
第一步：從能力與信任邊界開始
把每個外掛需求寫成能力清單：日誌、現在時間、設定讀取、物件讀取或佇列提交。能力不是註解，而是宿主實際提供的 imports。只需純計算的 world 不應擁有檔案或網路介面；拒絕預設提供「萬能宿主 API」。對不可信外掛，將 Wasm 隔離視為一層防線，並結合程序級資源限制、簽名發布和依賴稽核。
第二步：區分核心模組與 Component
核心模組定義低階函式、表、線性記憶體和匯入匯出，適合單一執行時或語言繫結。它們跨模組傳遞字串、清單等複合值時，通常需要共享記憶體佈局和手工 ABI，容易形成語言耦合。Component 把一個或多個核心模組包在自描述容器中，用介面型別表達 strings、records、variants、results 等值，並透過 Canonical ABI 規定跨邊界適配。
world rules {
import logger: interface { log: func(level: string, message: string) }
import objects: interface { read: func(key: string) -> result<list<u8>, not-found> }
export evaluate: func(input: list<u8>) -> result<list<u8>, rule-error>
}這段 WIT 風格宣告表達的是邊界，不是某種語言的實作。宿主應驗證元件宣告與允許 world 的匹配，拒絕額外匯入；外掛只看到介面，不直接取得宿主指標或檔案描述元。
第三步：解釋 WIT world 與 WASI
WIT 檔案定義介面以及 import/export 方向，world 是一組介面的閉合契約。宿主可以把一個元件的 export 連接到另一個元件的 import，這種組合不需要共享記憶體。WASI 使用相同介面描述方式提供檔案、網路、時間等系統能力，但執行時仍需配置目錄映射、網路權限和資源限額；實作 WASI 不代表自動開放所有能力。
第四步：設計生命週期與資源控制
為每個元件實例設定記憶體上限、呼叫逾時、燃料或執行預算、併發上限和輸出位元組上限。短呼叫可使用實例池並在請求間清理狀態；有狀態外掛則把狀態顯式放在宿主物件中。取消時停止新呼叫，等待或終止實例，並記錄是否已產生外部副作用。不要把「呼叫返回錯誤」誤當成外部寫入已回滾。
第五步：處理版本與跨語言相容
介面新增可選欄位通常比改變既有欄位安全；刪除或改變語意需要新 world 或遷移窗口。發布元件時鎖定 WIT 套件、執行時、適配器和能力清單，記錄元件雜湊與依賴版本。升級先在影子實例執行，比較結果、延遲和資源消耗，再按租戶或外掛版本灰度。舊元件繼續繫結舊 world，避免宿主把新介面強行映射成舊語意。
第六步：用測試證明邊界與收益
安全測試覆蓋未宣告 import、路徑穿越、網路越權、資源耗盡、惡意超大返回值和元件簽名錯誤。相容測試覆蓋不同語言產生相同 WIT 值、可選欄位、錯誤 variants 和宿主/元件獨立升級。效能測試分離元件邊界適配、冷啟動、實例池命中和業務計算時間；如果大多時間都在複製資料，原生庫或獨立服務可能更合適。
高品質示範回答
我會先確認外掛信任級別和能力需求。對於受控合作夥伴外掛，我用 WIT 定義一個最小 world：外掛匯出規則評估，只匯入結構化日誌和受限物件讀取。宿主實例化 Component 時只連接這些 imports，並在執行時設定記憶體、時間、併發和輸出上限。純計算外掛的 world 不提供檔案和網路。
核心 Wasm 模組提供低階可驗證執行，但跨語言複合值容易依賴共享記憶體 ABI。Component Model 用型別化介面和 Canonical ABI 包裝模組，WIT 描述介面方向，WASI 只是可選的標準系統能力集合；我仍要配置目錄、網路和時間權限。版本方面，我把 WIT 套件、適配器、執行時和元件雜湊鎖在發布物中，舊 world 保持可用，先影子執行新版本再灰度。
最後我會驗證越權匯入、資源耗盡、錯誤重試和外部副作用，測量冷啟動、邊界適配、實例池命中及業務計算時間。如果外掛完全不可信、需要複雜網路或大量共享狀態，我會改用獨立服務和更強的程序隔離，而不會把 Wasm 沙箱當成萬能安全方案。
常見錯誤
- 把 WebAssembly 當成可直接存取系統呼叫的程序 → 核心模組沒有環境 API，能力來自宿主 imports → 列出每項 import，並按最小權限配置。
- 把 Component 當成更快的核心模組 → 它主要解決型別化介面、組合和跨語言 ABI，邊界適配可能增加成本 → 用基準拆分冷啟動、適配和業務計算。
- 給所有外掛開放完整 WASI → 檔案、網路和時間能力會擴大資料洩露與資源濫用面 → 按 world 和租戶授予能力，預設拒絕。
- 只驗證函式返回值 → 逾時後外部寫入可能已發生，重試會造成重複副作用 → 為副作用定義冪等鍵、稽核和未知結果狀態。
- 宿主升級後強行填充舊介面 → 型別相同不代表語意相同 → 並行支援版本化 world，顯式遷移。
追問及應對
追問一：為什麼不用容器執行外掛？
容器適合需要獨立檔案系統、網路堆疊和程序級故障邊界的外掛，但啟動和資源開銷通常更高。Component 適合短呼叫、明確能力和高密度實例；如果外掛需要獨立核心權限、特殊驅動或強隔離，容器或獨立服務更合適。選擇依據是威脅模型、啟動目標、資源預算和維運能力。
追問二：元件呼叫一個外部寫入後逾時，能否自動重試？
不能僅憑逾時判斷未寫入。宿主應把請求識別碼和冪等鍵傳給外部系統，記錄 UNKNOWN 狀態並透過查詢或補償流程確認。只有確認未執行或外部契約保證冪等時才重試；不能聲稱 Component Model 提供跨系統交易。
追問三：如何阻止外掛把日誌當成資料外傳？
日誌介面也屬於能力。限制欄位長度、結構和速率，進行敏感欄位標記與租戶隔離；高風險外掛使用脫敏代理或完全不给日誌 import。執行時稽核只記錄元件版本、能力和呼叫計數，不把日誌內容當成安全證明。
追問四：WASI Preview 版本變化怎麼辦？
把 WASI 介面套件和執行時版本寫入元件發布清單，相容矩陣作為部署門禁。新執行時先在舊 world 上執行回歸和結果對照，發現介面或語意差異就保留舊執行時或適配器。不要把「實作了 WASI」當成跨版本相容承諾。