Deno 2.9 正式釋出：原生桌面應用、後量子密碼學與全面效能躍升
deno.com · 2026-06-25
Deno 團隊於 2026 年 6 月 25 日發布 v2.9.0，這是該執行環境自 2.0 以來規模最大的一次更新。本版本引入實驗性桌面應用程式建置能力、NIST 後量子密碼演算法支援，以及對啟動速度與記憶體佔用的大幅改善。冷啟動時間從 34ms 壓縮至 17ms，記憶體使用量最多降低 3.1 倍，HTTP 吞吐量亦提升約 11–27%。
實驗性桌面應用：deno desktop
deno desktop 子命令讓開發者能直接以現有 Web 框架（如 Vite 專案）建置原生桌面應用程式，無需引入 Electron 的龐大依賴樹。輸出為單一可執行二進位，預設後端為 Webview，亦可選用 CEF。
新增的原生 API 包括：
Deno.BrowserWindow— 控制視窗的建立、大小與標題Deno.Tray— 系統列圖示與選單Deno.Dock— macOS Dock 徽章與行為
安裝封裝格式方面，Linux 支援 .deb/.rpm，Windows 支援 .msi，並可搭配 deno compile --bundle 進一步壓縮二進位體積。
套件管理器遷移：無縫讀取既有鎖定檔
deno install 現在能直接解析 npm、pnpm、Yarn 及 Bun 的鎖定檔（package-lock.json、pnpm-lock.yaml、yarn.lock、bun.lock），並自動將依賴版本植入 deno.lock，讓現有 Node.js 專案無需手動調整即可切換至 Deno。
此外，deno install 也能偵測 pnpm workspace 結構，自動完成工作區成員的模組初始化。對於仍需要裸 node 二進位的工具，新增的 Node shim 機制可將呼叫代理至 Deno 執行時期。
新子命令 deno list 可列出專案所有宣告的依賴，deno link/deno unlink 則提供本機套件的連結管理，類似 npm link 的工作流程。
測試工具全面升級
本版本為 Deno 的測試框架新增多項長期被社群請求的功能。內建快照測試透過 t.assertSnapshot() 實現，毋須額外安裝測試函式庫。
Deno.test.each()— 參數化測試，減少重複的測試案例定義--changed旗標 — 僅執行與目前 Git 變更相關的測試--shard旗標 — 將測試集分片分配至多個 CI 工作節點並行執行- Retry 與 repeat 選項 — 對不穩定測試設定自動重試次數
- Coverage threshold 強制執行 — 低於門檻即中斷 CI
測試報告亦新增次毫秒級時間顯示，便於分析慢速測試瓶頸。
後量子密碼學與 Web 標準擴充
NIST FIPS 標準後量子演算法 ML-KEM、ML-DSA、SLH-DSA 已整合進 SubtleCrypto，與現行 Web Crypto API 介面保持一致。同批新增的還有 ChaCha20-Poly1305 AEAD 對稱加密、SHA-3 系列雜湊函式、XOF（可擴展輸出函式），以及密碼雜湊演算法 Argon2。
新增 SubtleCrypto.supports() 方法可在執行期查詢當前環境支援哪些演算法，免去硬編碼演算法名稱後的例外捕捉邏輯。WebCrypto 的核心實作亦已從 JavaScript 移植至 Rust，進一步提升效能。
供應鏈安全方面，npm 信任政策新增 no-downgrade 選項，可防止攻擊者利用被盜的維護者 token 發布舊版惡意套件；預設的 24 小時最低依賴套件年齡規則也正式啟用。
格式化工具、任務系統與 Node.js 相容性
deno fmt 現在支援 CSS、SCSS、Less（透過 lax-css）、SQL（透過 lax-sql）及 HTML/XML/SVG（透過 lax-markup）的格式化，並能自動讀取 .editorconfig 推斷縮排與換行規則。Named imports/exports 排序選項也已加入，方便維持一致的匯入順序。
deno task 新增輸入導向快取機制，可追蹤來源檔案、輸出產物與環境變數，當輸入未變更時跳過重複建置。同時支援 --jobs 控制任務並行度，以及 --if-present 條件式執行。
Node.js 相容性目標已升至 Node.js 26，裸模組識別符（如 import "fs"）無需任何設定即可解析。node:test 模組新增 mock.module、mock.timers 及 fileSnapshot 功能，使現有 Node.js 測試套件的移植更為順暢。
Vue 3.5.39 修補釋出：修正 Hydration、SSR 與 Teleport 的多項邊界情況
github.com/vuejs/core · 2026-06-25
Vue.js 核心團隊於 2026 年 6 月 25 日釋出 v3.5.39 修補版本，共涵蓋 14 項錯誤修正，涉及編譯器、響應式系統、SSR 渲染、Teleport 以及 TypeScript 型別定義。本次更新延續 3.5 穩定版的維護節奏，未引入新功能，建議所有使用 Vue 3 的專案盡快升級。
Hydration 與 SSR 渲染修正
本版本針對伺服器端渲染（SSR）的水合（hydration）流程修復了兩個問題。動態 props 在水合時強制進行 patch（#9083），解決了部分動態屬性在 SSR 場景下未被正確同步至客戶端 DOM 的問題。
另一修正讓 data-allow-mismatch 屬性能夠在條件式分支（v-if/v-else）上正確發揮作用（#12801）。此屬性原用於允許特定節點在 SSR 與 CSR 之間存在差異，但先前在條件分支情境下未能正確套用。
SSR 層另有兩項修正：vnode 渲染時去重繼承的 scope ID（#15005），以及修復巢狀非同步 Teleport 內容的解析順序問題（#9431）。
響應式系統與執行時期核心
響應式（Reactivity）模組修正了一個當 set 操作失敗時仍會觸發副作用（effect）的問題（#14964）。僅在 set 真正成功後才觸發依賴更新，避免了不必要的重新渲染。
執行時期核心（runtime-core）共包含四項修正：
- 修正非同構 block 元素更新時的處理邏輯（#15002）
- 為元素與 Teleport 的 function children 進行正規化（#9108）
- 呼叫 function ref 時暫停響應式追蹤，避免誤收集依賴（#14985）
- 保留
.once修飾符的事件監聽器名稱（#8341）
編譯器、Teleport 與型別修正
編譯器核心（compiler-core）修正了過濾器（filter）改寫時的遞迴邏輯問題（#14959），避免在特定巢狀表達式中產生錯誤的輸出。Teleport 的卸載邊界情況也在本次得到修正（#12705），防止元件在特定條件下卸載時發生例外。
runtime-dom 修正了事件名稱帶有 .option 修飾符時無法正確保留名稱的問題（#8338）。TypeScript 型別定義方面，新增對具名元組（named tuple）在 emits 中的支援（#12676），並為 defineModel 的 defaults 選項加入型別驗證（#14968）。
Mozilla 為 AI 開發工具打造 MDN MCP 伺服器，網頁相容性資料即時上線
MDN Blog · 2026-06-15
Mozilla 於 2026 年 6 月 15 日正式發表 MDN MCP Server，這是一項以 Model Context Protocol（MCP）為基礎的實驗性服務，讓 AI 程式助理與 IDE 外掛能夠直接查詢 MDN 的文件庫與瀏覽器相容性資料。目標是解決 LLM 訓練資料具有截止日期的根本問題，避免開發者收到過時的 Web API 建議。
背景：LLM 的知識截止日期問題
大型語言模型在訓練完成後便無法主動取得新發布的 Web 平台資訊。以 CSS @view-transition at-rule 為例，若 LLM 的訓練資料未涵蓋該特性，就可能給出無效或不完整的使用範例。瀏覽器相容性更是高度動態的資訊——光是今年 Firefox 151 就新增了 Web Serial API 支援——這類變動難以被訓練資料即時反映。MDN MCP Server 正是為了填補這道落差而生。
核心功能
MDN MCP Server 透過遠端 HTTP 傳輸提供三大工具：MDN 全文搜尋、Web 平台文件內容、以及 BCD（Browser Compatibility Data）查詢。伺服器架設於 https://mcp.mdn.mozilla.net/，無須本地安裝即可直接使用。對於有隱私顧慮的團隊，MDN 也提供了在本地端（預設 port 3002）自行部署的選項；原始碼已以 Mozilla Public License 2.0 授權開放於 github.com/mdn/mcp。
安裝與整合方式
以 Claude Code 為例，只需一行指令即可完成設定：
claude mcp add --transport http mdn https://mcp.mdn.mozilla.net/此外，MDN MCP Server 也支援 VS Code、Zed、Cursor 等主流編輯器，以及 Codex CLI 和 Antigravity CLI 等 Agent 工具。各平台的設定方式可分別參閱 VS Code 官方文件、Zed 文件與 Cursor 文件。
實測效果比較
MDN 團隊在文章中展示了啟用 MCP 前後的回答差異。啟用後，LLM 能夠正確回報 Firefox 151 已支援 Web Serial API，而未啟用 MCP 的版本則給出「Firefox 不支援」的錯誤答案。在回應速度方面，整合 MCP 後的速度約為原先的兩倍，原因在於 LLM 不再需要對不確定的相容性資訊進行大量推理。
| 比較項目 | 無 MCP | 有 MDN MCP |
|---|---|---|
| 瀏覽器相容性準確度 | 依賴訓練資料，可能過時 | 即時查詢 BCD，反映最新狀況 |
| 新特性覆蓋率 | 受訓練截止日期限制 | 可查詢最新發布的 Web 平台功能 |
| 回應速度（實測） | 基準值 | 約快 2 倍 |
實驗性質與隱私注意事項
MDN 強調此服務目前仍屬實驗階段，隨時可能下線，不建議作為生產環境的強依賴。在資料蒐集方面，服務會記錄查詢內容，但不會與使用者身份綁定；若需停用分析追蹤，可在請求中加入 X-Moz-1st-Party-Data-Opt-Out: 1 標頭。問題回報與功能建議可至 GitHub Issues 或 MDN Discord 社群提交。
原始來源：MDN Blog — Introducing the MDN MCP server、github.com/mdn/mcp、MDN MCP 官方頁面
2026 年 WebAssembly 執行環境效能總評：Wasmer 奪冠，wide_arithmetic 成決勝關鍵
00f.net · 2026-06-23
資安研究員 Frank DENIS 於 2026 年 6 月 23 日發布了年度 WebAssembly 執行環境效能測試報告，橫跨 2024 至 2026 年的追蹤數據，涵蓋 9 款主流 Wasm 執行環境。今年的最大亮點是 wide_arithmetic 指令集擴充帶來的顯著提升，以及 Wasmer 首次在綜合評比中拿下最佳成績。
背景與測試方法
測試基準採用 libsodium 密碼學函式庫編譯而成的 WebAssembly 模組，以加密運算的幾何平均值作為對原生 x86-64 執行速度的相對指標（slowdown ratio）。硬體平台為 AMD Ryzen AI 9 HX 470，鎖定 2 GHz 並停用 CPU boost 以確保數據一致性。測試分為四種建置配置：
- 純 WebAssembly 基線（無額外 CPU 特性）
- 啟用
lime1特性的建置 - 啟用
simd128的建置 - 啟用
wide_arithmetic（目前 Phase 3 提案）的建置
2026 年排名結果
Wasmer 以 1.33 倍原生速度的成績拿下第一，且必須在啟用 wide_arithmetic 的條件下才能達到此數值。以下為各執行環境在最佳支援建置下的排名：
| 排名 | 執行環境 | 最佳相對速度（倍於原生） | 關鍵配置 |
|---|---|---|---|
| 1 | Wasmer | 1.33× | wide_arithmetic |
| 2 | WAVM | 1.41× | — |
| 3 | WAMR AOT | 1.42× | — |
| 4 | Wasmtime | 1.46× | wide_arithmetic |
| 5 | WasmEdge | 1.64× | — |
wide_arithmetic 提案的實際影響
wide_arithmetic 是一個目前處於 Phase 3 的 WebAssembly 提案，主要新增了用於 128 位元及更寬整數運算的原生指令，使密碼學、大數運算等場景無需借助 SIMD 繞路即可高效執行。根據本次測試，支援該提案的執行環境（Wasmer、Wasmtime）其 slowdown ratio 相較未啟用時下降約 40%，顯示這項提案在計算密集型工作負載上的潛力相當可觀。
各執行環境三年趨勢觀察
從 2024 到 2026 年的縱向資料中，Wasmtime 展現最穩定的年年進步幅度，Bytecode Alliance 的持續投入可見一斑；Bun 則在 2025 至 2026 年間出現大幅躍升，反映了 JavaScriptCore 底層 Wasm JIT 的積極優化。相比之下，Wazero 整體數值穩定但進展趨緩，作為純 Go 實作的執行環境，在高度密碼學工作負載下仍面臨先天限制。
- Wasmtime：三年連續改善，最具持續性
- Bun：2025→2026 年間出現大幅提升
- Wazero：純 Go 實作，數值平穩但成長停滯
- Node.js：基於 V8，表現中規中矩
測試侷限性說明
作者明確指出，此測試僅代表密碼學計算場景，不能直接類推至通用 Wasm 工作負載。libsodium 的計算特性偏向整數密集，對 SIMD 與 wide_arithmetic 較為敏感；圖形渲染、字串處理或 I/O 密集型場景的執行環境排名可能大相逕庭。此外，WAVM 雖然排名第二，但其開發活躍度相對較低，在選擇執行環境時仍需考量社群支援與長期維護能力。
原始來源：00f.net — Performance of WebAssembly runtimes in 2026、github.com/bytecodealliance/wasmtime、WebAssembly wide-arithmetic 提案