Vue 3.6 釋出首個候選版：Vapor Mode 登場、反應式核心換血成 alien-signals
GitHub Releases (vuejs/core) · 2026-07-18
Vue 核心團隊於 2026-07-18 發布 v3.6.0-rc.1，這是 3.6 版本正式進入候選階段的第一個版本。本次釋出的兩大主軸是全新編譯模式 Vapor Mode，以及 @vue/reactivity 套件的底層重構。兩者都以「選擇性啟用」的方式導入，不影響既有專案的執行方式。
核心改動：Vapor Mode
Vapor Mode 是一種新的單檔案元件（SFC）編譯模式，目標是縮小基礎打包體積並提升執行效能。開發者可以用 <script setup vapor> 撰寫元件，或使用純模板的 SFC；官方在第三方基準測試中宣稱其效能已可與 Solid、Svelte 5 等框架打平。
<script setup vapor>
import { ref } from 'vue'
const count = ref(0)
</script>
<template>
<button @click="count++">{{ count }}</button>
</template>
Vapor 元件不經過虛擬 DOM（VNode），因此不支援 Options API，也與依賴 VNode 或元件實例代理（instance proxy）的功能不相容，例如 app.config.globalProperties、getCurrentInstance()、逐元素生命週期事件、v-memo 與元件模板 ref 屬性。純 Vapor 應用需改用 createVaporApp() 建立；若要在同一個應用中混用傳統 VDOM 元件與 Vapor 元件，則需要額外掛載 vaporInteropPlugin。
核心改動：反應式核心改用 alien-signals
@vue/reactivity 這次做了大規模重構，改以 alien-signals 演算法為基礎。alien-signals 最早是 Vue 核心維護者在獨立專案中實驗的 push-pull 混合式訊號演算法，靈感來自 Preact 的雙向鏈結串列設計；相較於 Vue 3.5 採用的純 pull-based 算法，push-pull 混合能減少不必要的重新計算。為了效能極限最佳化，其核心演算法刻意不使用 Array、Set、Map 等結構，也避免函式遞迴，並以疊代式堆疊（stack-based）取代遞迴呼叫來實作內部的 propagate 與 checkDirty。這次是把該演算法反向移植回 Vue 本體，使 Proxy 之外的響應追蹤路徑更輕量、記憶體占用更低。
影響範圍
本版另含十二項針對 hydration 與 runtime-vapor 的錯誤修正，涵蓋 hydration 過程中的 slot 處理與互操作、動態元件的 VNode anchor 保留，以及 Transition 支援的改善。由於這是 rc.1（release candidate 第一版）而非正式版，且 Vapor Mode 與 alien-signals 兩項改動皆為選擇性啟用，現有專案升級時預期不需要更動程式碼即可維持原行為；真正要使用 Vapor Mode 的專案則需要評估上述 Options API 與實例代理相關功能的相容性。
WHATWG 發布 2026 年 7 月 HTML 標準審閱草案，並修正自訂元素與解析演算法的規格瑕疵
WHATWG HTML commits · 2026-07-17
WHATWG 於 2026-07-17 提交 746f2ed「Review Draft Publication: July 2026」，為 HTML Living Standard 產生當月的審閱草案快照。這類提交本身通常只是把規格文件的當前狀態封存成一份可供外部審閱、引用的固定版本，不代表新增功能，但同一批次前後幾天內，編輯 Anne van Kesteren 同時推送了多筆修正解析演算法與自訂元素行為的規格提交。
規格細節：自訂元素建構器映射表修正
其中一筆修正 e05b3e5「Restore active custom element constructor map entries after construction」，處理的是自訂元素在多重登錄表（custom element registry）下的重入升級（re-entrant upgrade）問題。規格內部維護一張以建構器（constructor）為鍵值的映射表，記錄目前正在執行升級的自訂元素對應哪個登錄表；問題在於，若同一個建構器被不同登錄表重複使用，內層升級會覆寫外層升級留下的映射項目，且該項目在讀取後、或升級完成時會被無條件移除，導致外層的 super() 呼叫讀到錯誤的登錄表。修正做法是在覆寫前先保存舊項目，事後還原，並停止在讀取時就清除它，讓外層登錄表能撐過內層的重入升級存活下來。此修正對應 DOM PR #1494、WPT 測試 #61364，並關閉了 issue #12691。
規格細節：解析演算法的措辭釐清
同批次還有三筆與 HTML 解析器（tree construction）相關的編輯修正。85f453b「Create nodes in the realm of the document they are created for」釐清節點建立時應歸屬哪一個 JavaScript realm；9377fd6「Remove inaccurate statement about the insertion mode and CDATA sections」移除一段關於插入模式（insertion mode）與 CDATA 區段的不精確描述；56674fb「Clarify that foreign content is not an insertion mode」則呼應了長年未解的 issue #4015，明確指出「外來內容（foreign content，即解析器切換到 SVG／MathML 語境的狀態）」在規格中並不是一個正式的插入模式，而是其他插入模式（如 in body、in table）在處理 token 時額外檢查的旁支條件。插入模式本身是解析器狀態機的核心變數，決定 tokenizer 產出的每個 token 該如何被插入 DOM 樹。
e05b3e5— 修正自訂元素建構器映射表在重入升級下的還原邏輯85f453b— 釐清節點建立所屬的 JavaScript realm9377fd6— 移除插入模式與 CDATA 區段的不精確敘述56674fb— 明確「外來內容」不是獨立的插入模式
影響範圍
這批提交多屬編輯性與正確性修正，不改變主流瀏覽器目前已實作的可觀察行為，但會影響瀏覽器引擎團隊對照規格撰寫或修正 Web Platform Tests 的依據，尤其是自訂元素登錄表這類較新、實作間仍在收斂細節的功能。對一般前端開發者而言，這些變動不需要調整程式碼，但若專案中使用了多重自訂元素登錄表（scoped custom element registries）並出現建構器重入的情境，可以留意各瀏覽器後續是否依此修正調整行為。
原始來源：Review Draft Publication: July 2026、custom element 建構器映射修正