SvelteKit 2.61：Remote Query 訂閱、TypeScript 6.0 支援與 query.live() API
Svelte Blog · 2026-06-01
Svelte 於 2026 年 6 月發布 SvelteKit 2.57.0 至 2.61.0 系列更新，引入遠端查詢訂閱（query.live()）、TypeScript 6.0 語言工具支援，以及多個 remote form API 的破壞性變更。最核心的架構改動是 remote queries 現在可以直接 await，不需要呼叫 .run()，並且在 2.59.0 引入的 query.live() 在 2.61.0 中升為穩定的 async iterable 支援。
Remote Query API 破壞性變更
SvelteKit 2.57.0 移除了 remote queries 的 .run() 方法，統一改為直接 await：
// 舊寫法（已移除）
const result = await query.run();
// 新寫法
const result = await query();Remote queries 現在在事件處理函式、async callbacks 以及模組作用域中均可 await，並內建共享 cache deduping——相同查詢在相同渲染週期中只發出一次網路請求。query.batch() 方法允許在單次網路往返中合併多個查詢，requested() 更新為必須傳入 limit 參數並回傳 { arg, query } 物件。
query.live()：長期訂閱查詢
在 2.59.0 作為實驗性功能引入、在 2.61.0 升為穩定的 query.live() 啟用「長期存活的遠端查詢訂閱」，以 async iterable 形式傳遞即時更新：
for await (const update of query.live()) {
items = update;
}這讓 SvelteKit 元件可以在不引入 WebSocket 或 SSE 函式庫的情況下消費伺服器推送的資料流，底層連線管理由 SvelteKit 框架處理。
TypeScript 6.0 與工具鏈更新
Svelte language tools 全線更新支援 TypeScript 6.0，涵蓋 language server、svelte2tsx、svelte-check 和 svelte-preprocess。TypeScript 6.0 引入的 isolatedDeclarations 選項讓大型 monorepo 的並行型別宣告生成成為可能，對使用 SvelteKit 的大型工程有實際的建構時間改善。vite-plugin-svelte 在開發模式啟用伺服器環境的 optimizer，減少冷啟動時的模組轉換負擔。
Svelte MCP 的 stdio 模式現在直接讀取檔案內容而非透過工具呼叫，減少 AI Agent 輔助開發工作流中的來回往返次數。模板（templates）更新允許在 markup 中直接宣告變數，讓值的定義更靠近使用位置，減少元件頂層的樣板程式碼。
原始來源：Svelte Blog
Zeroserve：以 eBPF 腳本化的零設定 io_uring HTTPS 伺服器
su3.io · 2026-06-07
Zeroserve 是一款基於 io_uring 的單執行緒 HTTPS 伺服器，以 Rust 撰寫，提供零設定部署、內建 TLS 1.3 與 Encrypted Client Hello、以及用戶空間 eBPF 腳本化能力。在單核心測試中，小型檔案（174 B）達到 36,681 req/s，優於 nginx 的 31,226 req/s；反向代理場景也比 nginx 高出 21%。
架構：tarball 直接服務
Zeroserve 以 tarball 作為部署單元：網站打包為單一 tarball，伺服器啟動時建立 path → byte-range 索引，所有請求直接對 tarball 做 byte-range 讀取，不在磁碟上解壓任何暫存檔。非同步 I/O 層使用 monoio（completion-based io_uring 執行環境），TLS 層使用 monoio-rustls。相較於 epoll 模型，io_uring 的 SQ/CQ 共享記憶體佇列避免了每次 I/O 完成所需的額外 syscall，在高 req/s 場景節省大量上下文切換成本。
eBPF 腳本的零 syscall 執行路徑
eBPF 整合採用純用戶空間執行模式：.zeroserve/scripts/ 下的 C 檔案在打包時以 clang + llc 編譯為 eBPF bytecode，執行期透過 async-ebpf（內嵌 uBPF）JIT 編譯為 x86-64 機器碼，無需 CAP_BPF 或 root 權限。記憶體安全靠 pointer cage——每個記憶體存取都被遮罩進腳本自身的 arena。預設 2ms 搶佔計時器防止腳本阻塞事件迴圈。
腳本 helper API 涵蓋：SHA-256/HMAC/base64、JSON 解析、token bucket 限速、AWS SigV4、OIDC relying-party，以及 zs_reverse_proxy()（維護最多 128 個上游連線池）。
效能對比
| 場景 | zeroserve | nginx | Caddy |
|---|---|---|---|
| 小型檔案 174 B（單核） | 36,681 req/s | 31,226 req/s | 12,830 req/s |
| 大型檔案 100 KB | 8,000 req/s (782 MB/s) | 7,600 req/s | — |
| eBPF 啟用（10ms 搶佔） | 43,709–46,945 req/s | — | — |
| 反向代理 | 26,486 req/s | 21,761 req/s | — |
閒置記憶體約 15 MB PSS；TLS 1.3、ECH、SNI 選取、JA4 指紋均為內建功能，零設定。
CPython JIT 開發暫停：Steering Council 要求提交正式 PEP 後才能繼續
Python Discussions · 2026-06-07
Python Steering Council 正式公告：CPython 的實驗性 JIT 編譯器在 Standards Track PEP 被接受之前，暫停所有新功能開發。錯誤修復與安全補丁不受影響。這是自 PEP 744 於 2024 年將 JIT 引入 CPython 主分支作為實驗性功能以來，最重大的治理層介入。
暫停背景
Steering Council 坦承，JIT 在未達成社群正式共識的情況下進入了主分支，缺少對幾個關鍵問題的明確答覆：長期維護可持續性、與效能剖析器和除錯器的相容性保證、與 free-threading 的互動、成功指標與效能目標時間表，以及與 CinderX、Numba、PyTorch 等第三方 JIT 方案的共存策略。Council 表示對「這種複雜度與影響範圍的變更」未嚴格執行 PEP 流程，並為此承擔責任。
CPython 目前的 JIT 實作基於 copy-and-patch 技術，已在部分基準測試中對特定 Python 工作負載顯示加速效果，但相容性與 ABI 邊界一直是 core developer 持續辯論的議題。
PEP 要求範圍
即將提交的 PEP 必須涵蓋：
- 明確的維護計畫與貢獻者影響評估
- 與現有 CPython 功能的相容性策略（尤其是 free-threading 與 C 擴充 ABI）
- 可量測的效能目標與平台覆蓋範圍（包含 WASM、iOS、Android）
- 可支援未來替代 JIT 後端的基礎設施設計
六個月窗口從公告日起算，由 Diego Russo 協調草稿撰寫。Steering Council 表示若 PEP 受阻，不會機械式觸發懲罰措施，保留彈性空間。已啟用 JIT 的 Python 3.14 穩定版本行為不受影響；影響的是 main 分支後續新特性的落地節奏。
原始來源：Python Discussions