Bytecode Alliance 5 大路線推進 Component Mod…
5 項工作線揭示 Bytecode Alliance 的 Component Model 1.0 路線，涵蓋 ABI、瀏覽器支援、工具鏈與生態補強。
這份清單整理 Bytecode Alliance 推進 Component Model 1.0 的 5 條工作線，讀完可判斷它離穩定版還差哪些關鍵拼圖。
WASI P3 已接近完成，但要把 Component Model 1.0 說成穩定版，還得補上 5 個面向：ABI、瀏覽器、實作門檻、生態工具與 WIT 表達力。這份路線圖的價值在於，它不只告訴你「會做什麼」，也讓你看得出哪一塊先落地、哪一塊會影響採用。
| 項目 | 規格 A | 規格 B | 規格 C |
|---|---|---|---|
| ABI 改進 | lazy values | multivalue returns | error context |
| 瀏覽器路徑 | 至少 2 個 engine 原生支援 | 移除 JS glue | 更佳效能訊號 |
| 實作簡化 | guest / host C ABI | lower-components | 保留 P3 中可用部分 |
| 生態成長 | docs / debugging / tooling | 語言支援擴張 | composition 與 registry |
| 表達力補洞 | optional imports | WIT 新特性 | 更好的可攜 API 設計 |
1. ABI 改進先動刀
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
這份路線圖最硬的部分，是把目前依賴 cabi_realloc 的 ABI 換成更省拷貝的做法。現狀能運作，但在碎片化、失敗處理與字串列表傳遞上都偏笨重。
新方向是 lazy value 模型：callee 先回傳不透明 handle，caller 需要時再把值具體化。這樣可減少搬運成本，也更適合零拷貝轉送。
- 0.3.x 版本先提供 opt-in lazy ABI
- 舊 eager components 仍可透過 adapter 相容
- C ABI 層支援 multivalue returns
- 失敗時附帶 error context
- GC 語言可走獨立 GC ABI
路線圖還把同步呼叫的額外成本列成目標：在 WASI P3 之後，component-to-component 的 sync path 要盡量做到零額外負擔。
2. 瀏覽器原生支援是關鍵訊號
Component Model 1.0 不只要能在瀏覽器跑，還要有至少兩個 browser engine 原生支援。現在 jco 已能把 components 轉成 core Wasm 加 JavaScript glue，所以「能跑」不是問題。
真正重要的是原生支援能否拿掉 glue layer，並在真實工作負載上證明效能。Mozilla 已向 WebAssembly CG 分享實驗結果，Chrome 的 V8 團隊也開了評估議題。
- jco 可發出 telemetry 的 use-components 訊號
- Mozilla 提過 DOM-heavy Wasm 的效能數據
- V8 團隊已開始評估原生整合
- 瀏覽器與非瀏覽器情境都可能受益
這條線看的不只是速度，而是採用訊號。只要瀏覽器願意把它當成原生能力，語言與框架團隊就更有理由往上游補支援。
3. 讓實作成本降下來
另一個重點是降低規格實作門檻。Bytecode Alliance 想把 1.0 保留在真正必要的部分，不再要求實作者背負所有過渡設計。
具體做法包括為 guest 和 host 定義 C ABI，並由 wit-bindgen 產生。guest 端可以先編成 core Wasm，再包成 component；host runtime 則可接較簡單的入口，不必從頭重做整套規格。
guest -> core wasm -> wasm-component-ld -> component
host runtime -> generated host C ABI -> component另外還有 lower-components 這類工具，能把多模組 component 壓成單一 core Wasm 模組，行為保持一致。這等於給 runtime 作者多一條較平滑的導入路徑。
4. 生態成長決定能不能落地
規格再漂亮，如果開發者用不起來，1.0 也只是紙上版本。所以路線圖把 docs、語言支援、工具鏈與除錯一起列進來，目標是讓 Component Model 工作流變得像一般開發流程一樣自然。
目前生態已有一些早期跡象：Rust、Tokio、LLVM 與 CPython 都在往前推，而 jco、wac、wkg 分別補上瀏覽器 glue、composition 與套件發佈。
- 各語言需要更多教程與參考文件
- 主要語言生態要補上 P3 支援
- composition 與 registry 工具要更完整
- WAVE traces 可支援 record / replay debugging
這一段看似不如 ABI 那麼硬核，卻最影響採用速度。當除錯、封裝、發佈都順手，component 才有機會從試驗品變成日常工具。
5. 把 WIT 的洞補齊
最後一條線是 WIT，也就是描述 component import 與 export 的介面語言。真實使用者已經碰到一些表達力不足的地方，1.0 不能把這些限制直接凍結下來。
其中一個例子是 optional imports。它讓 component 可以宣告自己在最小 host world 下也能運作，只有在環境提供額外能力時才用上去，對可攜式 library 和 app 特別重要。
- optional imports 支援 capability-aware components
- 依實際使用補進更多 WIT 特性
- 讓 portable standard libraries 更好做
- 跨不同 host 的 API 設計更一致
這部分不一定最搶眼，卻會直接決定模型好不好用。WIT 若太僵硬，整個 stack 都會變難採用；補對地方，component 才能兼顧可攜性與主機整合。
怎麼挑
如果你是 runtime 或編譯器工程師，先看 ABI 改進與實作簡化；如果你在做瀏覽器整合，瀏覽器原生支援是最值得追的訊號；如果你負責語言工具、文件或發佈流程，生態成長這一項最接近你的日常工作。
對多數讀者來說，這份路線圖的重點很清楚：Component Model 1.0 不是單一功能上線，而是一組協同變更，目的是讓今天的 component 繼續可用，明天的 component 更容易做、跑得更快、也更好發佈。