TC39 Iterator Chunking 提案升至 Stage 3：chunks() 與 windows() 正式進入規範軌道
TC39 Proposals · 2026-06-08
TC39 iterator chunking 提案已晉升至 Stage 3，這代表規範文字已完整且實作即將展開。提案為 Iterator 協定新增兩個方法：chunks(size) 與 windows(size)，分別對應非重疊批次與滑動視窗兩種常見的序列切割模式。
規格細節
chunks(size) 將迭代器切割成長度固定的子迭代器序列，最後一個片段在元素不足時照舊回傳剩餘元素。windows(size) 則產生重疊的滑動視窗，相鄰視窗各差一個元素。兩者都回傳惰性迭代器，不預先具現化整個序列。
// chunks：分頁、批次處理
[0,1,2,3,4,5,6,7,8,9].values().chunks(3)
// → [[0,1,2],[3,4,5],[6,7,8],[9]]
// windows：滑動計算、相鄰比較
[0,1,2,3,4,5,6,7,8,9].values().windows(2)
// → [[0,1],[1,2],[2,3],...,[8,9]]提案規範全文已發布於 tc39.es/proposal-iterator-chunking/。Stage 3 代表 API 形狀固定，不會再有破壞性更動，瀏覽器與 runtime 可開始實作。
背景
JavaScript 的 Iterator Helpers 提案（map、filter、take 等）已於 2024 年底達到 Stage 4，但分批處理與滑動視窗被拆分為獨立提案延後處理。此前開發者需自行實作或依賴 lodash _.chunk、Ramda R.splitEvery 等工具函式庫。
chunks 的典型用例包括分頁邏輯、矩陣運算列填充與網格布局；windows 適合移動平均計算、差分序列分析與 carousel 相鄰元素偵測。兩種操作本質相同但語義差異明顯，設計上以兩個方法分開表達而非單一旗標參數。
影響範圍
Stage 3 規範通常在 6–12 個月內出現在 Chrome、Firefox 實驗旗標後，再於半年到一年間進入 stable。Node.js 通常緊跟 V8 進度。TypeScript 會在 Stage 3 後為新方法加入型別宣告，讓 TS 專案可提早啟用 polyfill。目前 core-js 尚未發布對應版本，但預計 Stage 4 後即會跟進。
TC39 Await Dictionary 升至 Stage 2.7：Promise.allKeyed() 解決命名式並行等待
TC39 Proposals · 2026-06-08
Await Dictionary 提案已達 Stage 2.7（規範文字完整、等待實作經驗回饋）。提案引入 Promise.allKeyed() 與 Promise.allSettledKeyed()，讓開發者以物件字面值而非陣列索引管理並行 Promise，消除位置依賴帶來的可讀性問題。
規格細節
傳統 Promise.all 以陣列位置對應結果，重構時若調換順序即會靜默引入 bug。Promise.allKeyed 接受一個以字串為鍵、Promise 為值的物件，回傳以同樣鍵名解構的結果物件：
// 舊寫法：位置依賴，容易出錯
const [shape, color, mass] = await Promise.all([getShape(), getColor(), getMass()]);
// 新寫法：命名對應，重構安全
const { shape, color, mass } = await Promise.allKeyed({
shape: getShape(),
color: getColor(),
mass: getMass(),
});Promise.allSettledKeyed 對應 Promise.allSettled 語義，每個鍵的值為 { status: 'fulfilled' | 'rejected', value | reason } 結構，適合需要逐鍵錯誤處理的場合。
影響範圍
提案由 Ashley Claymore、Jordan Harband、Chris de Almeida、Rick Waldron 共同擔任 champion。Stage 2.7 代表 API 設計不會再有重大更動，實作者可在 polyfill 或 transpiler 外掛中率先支援。核心使用情境是任何需要命名式並行 fetch 的模組——API 聚合層、伺服器元件 data loader 等。由於只是 Promise.all 的語法糖包裝，polyfill 實作極為輕量，可立即在生產環境部署而不等待原生支援。
io_uring 自動緩衝區管理：UringMachine 的 Buffer Ring 實作解析
noteflakes.com · 2026-06-07
Ruby 的 UringMachine 函式庫在 2026-06-07 發布了自動緩衝區管理功能，利用 Linux io_uring 的 buffer ring 機制，讓核心在執行多路並行 multishot read 時自動選取可用緩衝區，無需每次 I/O 前手動提交緩衝區。
核心改動
Buffer ring 是 io_uring 5.19 引入的機制：使用者空間預先向核心登記一組緩衝區，核心在 recv_multishot 或 read_multishot 等操作完成時自動從 ring 中取用緩衝區並在 CQE 中回報使用的 buffer ID，省去每次 I/O 的系統呼叫往返。UringMachine 在此基礎上維護總量 256 KB（128–256 KB 範圍）的可用空間，當遭遇 ENOBUFS（ring 耗盡）時自動倍增容量。
讀取結果以分段緩衝區（segmented buffer）的形式回傳，內部以連結串列組織各段，避免跨段複製資料。物件池（free list）重用 segment struct 與操作元資料，減少 GC 壓力。同一 buffer group 可同時服務任意數量的並行 multishot read，非常適合高並行 socket 處理。
# 高層 API 抽象
io.read_line(socket) # 讀到換行符
io.read_to_delim(socket, delim: "\r\n\r\n") # 讀到分隔符影響範圍
自動緩衝區管理消除了傳統事件迴圈中「提交緩衝區→等待完成→回收緩衝區」的三步驟開銷。對於每連線資料量小但並行連線數高的應用（如 HTTP/1.1 keep-alive、WebSocket、Redis 協定實作），此設計可顯著降低每請求記憶體分配次數。Linux 5.19 以上核心才支援 buffer ring，Ubuntu 22.10+、Debian 12+ 均滿足此要求。
原始來源：noteflakes.com 原文