2026-05-29 — Rust 1.96.0 新 Range 型別、Just Use Postgres for Durable Workflows

Rust 1.96.0 正式發布：新 Range 型別、assert_matches! 與 Cargo 安全修補

Rust Blog · 2026-05-28

2026 年 5 月 28 日，Rust 官方釋出 1.96.0 穩定版，帶來 RFC 3550 定義的新 range 型別、兩個斷言巨集的穩定化，以及 WebAssembly 連結行為的重大變更。同步修補 Cargo 的兩個安全漏洞 CVE-2026-5223 與 CVE-2026-5222。

新 Range 型別（RFC 3550）

標準函式庫新增了 core::range 模組，收錄三個實作 IntoIterator 而非 Iterator 的 range 型別：

• core::range::Range
• core::range::RangeFrom
• core::range::RangeInclusive（並公開欄位）

核心動機是讓 range 型別可以實作 Copy——同時實作 Iterator 與 Copy 是一個陷阱（range 的迭代狀態會隨複製一起帶走，造成預期外的行為）。新型別透過分離「可迭代」與「迭代狀態」解決此問題。未來 Rust 版本（edition）將把 0..1 語法產生這些新型別而非舊版 range。

assert_matches! 與 debug_assert_matches!

兩個新巨集已穩定化，作為 assert!(matches!(..))` 的強化版本：

use std::assert_matches::assert_matches;

let x = Some(42);
assert_matches!(x, Some(n) if n > 0, "expected positive");
// 失敗時印出：panicked at 'assertion failed: matches!(x, Some(n) if n > 0, "expected positive")'

兩個巨集未加入 prelude，需手動從 core 或 std 匯入，以避免與現有第三方 crate 命名衝突。

WebAssembly 連結行為變更

WebAssembly 目標不再自動傳遞 --allow-undefined 給連結器。未定義符號現在直接造成連結錯誤，而非被轉換為從 "env" 模組匯入的 WebAssembly import——這樣可在更早期捕獲程式錯誤。

若有既存程式碼需要舊行為，可透過 RUSTFLAGS=-Clink-arg=--allow-undefined 還原。

Cargo 安全修補

同版本一併修補兩個 Cargo 漏洞（僅影響非 crates.io 的私有 registry 使用者）：

• CVE-2026-5223（Medium）：crate tarball 解壓縮時的符號連結提取問題
• CVE-2026-5222（Low）：帶有正規化 URL 的認證流程問題

原始來源：Rust Blog — Announcing Rust 1.96.0

以 PostgreSQL 作為持久執行基礎設施：Just Use Postgres

DBOS Blog · 2026-05-28

DBOS 工程師發表一篇深度技術文，主張 PostgreSQL 足以承擔持久工作流（durable workflow）的底層基礎設施需求，不必引入 Temporal、Conductor 或 Kafka 等專用系統。文章探討如何用 Postgres 的交易性與持久性特性實作 durable execution 的核心語意。

持久執行的核心需求

持久工作流引擎需要在以下情境下保證「恰好一次（exactly-once）」語意：程式崩潰、重啟、網路分割。核心問題是：工作流的執行歷程（execution log）必須在決定性位置被持久化，以便在任意時間點重放。

Postgres 如何滿足需求

Postgres 透過以下機制支撐 durable execution：

• WAL（Write-Ahead Log）：所有狀態變更先寫入 WAL 再提交，提供崩潰後可重放的持久紀錄
• SERIALIZABLE 交易：工作流步驟的前提條件（precondition）與結果可原子性寫入，防止重複執行
• LISTEN / NOTIFY：輕量的跨連線事件傳遞，作為工作流步驟完成信號
• Advisory locks：防止同一工作流實例被多個 worker 並行處理

實作模式

典型做法是在 Postgres 中維護一張 workflow_steps 表，欄位包含步驟 ID、輸入、輸出、狀態與版本號。worker 在執行每個步驟前以 INSERT ... ON CONFLICT DO NOTHING 嘗試取得所有權；若步驟已完成，從 DB 讀出先前結果並繼續——這即是「重放（replay）」。整個工作流狀態機運行於 Postgres 交易保證之上，不需要外部協調層。

適用邊界

文章也直言限制：Postgres 單節點吞吐量會成為瓶頸（典型 ~5k–10k 步驟/秒），跨資料庫的分散式工作流需要額外設計，以及超高並發場景仍可能需要更專用的系統。對於大多數工程團隊而言，這種方法在 Postgres 能力邊界內已足夠，並減少了運維複雜度。

原始來源：DBOS Blog — Just Use Postgres for Durable Workflows