Gecko 是用 Rust 写的 GameCube/Wii 模拟器与调试器，目标同时覆盖 Homebrew、逆向与可玩体验。核心使用 Cranelift 做 PowerPC、DSP 与顶点解码 JIT，渲染走 wgpu，并提供 egui 调试 UI、FIFO 录制/回放、Lua 脚本与 MCP 等开发者工具。跨平台支持 Windows/Linux/macOS，以及 x86 与 ARM。

本轮更新带来整体性能提升，许多原先“能启动但帧率不够玩”的游戏现已可玩，例如 LEGO Batman。新增 savestates，可在任意时刻存档并恢复。调试器支持 freecam：解锁相机后可脱离游戏镜头观察场景。作者表示 Super Mario Galaxy 系列与多款 LEGO 游戏现已 fully playable，并放出 Galaxy 实机视频；dev/nightly 分支还有使 Xenoblade Chronicles 可工作的修复。GitHub 提供每日 nightly 构建，截图兼容库见 emu.layle.dev。作者还预告了基于同一核心的多系统模拟器，浏览器端 SNES 已可运行。

原文链接：https://github.com/ioncodes/gecko

用 ESP32 在 Rust 里实现 STM32 的 SWD 编程器

文章是嵌入式实验笔记：在没有 ST-Link 的情况下，用 ESP32 DevKit 充当 SWD 主机，对 STM32F103C8T6 Blue Pill 实现 Serial Wire Debug 通信。本篇完成用 Rust bit-bang SWD 读取目标 DP 的 IDCODE；真正刷写固件留到下一篇。

硬件上 ESP32 与 Blue Pill 各自 USB 供电，信号线为 GPIO18→SWCLK(PA14)、GPIO19→SWDIO(PA13)，并共地。文中从 SWD 双线协议讲起，用 Flex 管理双向 SWDIO，实现 clock、write_bit/read_bit 以及 LSB-first 的多位读写；并按 ARM 规范完成 JTAG→SWD 切换序列（不少于 50 个 SWDIO 高电平时钟周期、发送 0xE79E、再拉高 50 周期）。示例代码仓库为 implferris/swd-rust-idcode。

原文链接：https://blog.implrust.com/posts/2026/09/swd-protocol-programmer-embedded-rust/

Empower：Rust + egui 可视化编程引擎

Empower 是作者业余约三年开发的可视化编程引擎，用 Rust 与 egui 实现，架构接近游戏引擎，希望同时服务初学者与需要复杂逻辑的开发者。开发者在图形编辑器中搭程序，再导出为面向目标操作系统的独立可执行文件。

仓库拆成三块：Empower Engine 提供节点图、资源、项目、编译、执行与导出等基础能力；Empower Studio 是 immediate-mode GUI 前端，含停靠窗口、项目/导出编辑与可视化日志；Empower Application 是目标机上的运行时可执行文件，规划支持 Linux/macOS/Windows。当前首发定位为 proof of concept。本地可 cargo build 后 cargo run -p empower-studio。

原文链接：https://github.com/Stretchyfish/empower

Drop 顺序应否写入函数 API 契约

作者在实现类似 smallvec 的 toy crate 时，注意到 Iterator::nth_back 的默认实现会反复调用 next_back，元素按反向顺序 drop；若为性能改用 ptr::drop_in_place 批量销毁，则变成正向 drop。标准库 std::vec::IntoIter::nth_back 同样是正向 drop。

讨论点在于：Rust 里 drop guard 很常见，跳过中间元素时的析构顺序是否应被视为函数 API 契约的一部分，还是仅作实现细节。相关行为可对照 Rust Reference 的 destructors 章节。

原文链接：https://www.reddit.com/r/rust/comments/1w8o4wx/do_you_think_drop_order_should_be_part_of_a/

From Rust中文社区 Mike

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区

最近我们在 MusicBrainz 数据集上测试了这样一个业务请求：

查询最新的 100 条、存在关联作品的 Recording，并为每条 Recording 加载最多 10 条 Work 关联。

我们分别用两种 SQLx 查询方案执行了这个请求。两条路径返回了完全相同的结果：

• 100 条 Recording；
• 103 条 Relation；
• 103 个 Link；
• 103 个 LinkType；
• 相同的 Work ID 校验值。

但两种 SQLx 实现的耗时分别是：

前两项是在同一个 SQLx 对照实验中测得的，性能差距约为 2378 倍。

TeaQL 的数据来自另一轮保留测试，用于提供背景参考，并不参与这个 2378 倍比值的计算。

因此，这个结果并不是说：

TeaQL 的 PostgreSQL 驱动比 SQLx 快 2000 多倍。

TeaQL 和优化后的 SQLx 最终都让数据库执行了范围明确的工作。真正造成巨大差异的，是两种执行计划所处理的数据量。

“显而易见”的 SQLx 写法

面对“每个父对象最多取 N 条子记录”这样的需求，熟悉 SQL 的开发者通常会想到窗口函数：

WITH ranked AS (
    SELECT
        relation.*,
        row_number() OVER (
            PARTITION BY relation.entity0
            ORDER BY relation.link_order ASC, relation.id DESC
        ) AS rn
    FROM recording_work_relation relation
)
SELECT ...
FROM recording
JOIN ranked
    ON ranked.entity0 = recording.id
   AND ranked.rn <= 10
WHERE ...
ORDER BY recording.id DESC
LIMIT 100;

从 SQL 表达能力来看，这条语句没有问题：

1. 按照 Recording 对 Relation 分组；
2. 对每组 Relation 排序；
3. 每组最多保留 10 条；
4. 最终返回最新的 100 条 Recording。

它看起来也很“优雅”：一个 SQL 语句、一个窗口函数，一次完成查询。

问题在于，数据库可能需要先对整个 Relation 集合进行分组和排序，然后才能知道哪些 Relation 属于最终选中的 100 条 Recording。

在这次 MusicBrainz 测试中，这个直观查询为了最终返回 103 条 Relation，对大约 270 万行数据进行了排名处理。

应用只需要一个很小的页面，数据库却先完成了一次全局工作。

业务请求其实给出了更强的边界

原始请求并不是：

找出所有 Recording 的前 10 条 Relation，再从中选择 100 条 Recording。

它真正表达的是：

1. 先确定最新的 100 条目标 Recording；
2. 只为这 100 条 Recording 查询 Relation；
3. 每个 Recording 最多加载 10 条 Relation；
4. 只加载这些 Relation 引用的 Link、LinkType 和 Work。

一旦先确定根对象，后续所有工作都可以限定在这 100 个 Recording ID 之内。

这意味着数据库不必对 270 万条 Relation 做全局排名。它只需要处理当前页面真正可能用到的数据。

这不是数据库驱动的性能差异，而是业务边界是否及时进入执行计划的差异。

优化后的 SQLx：先选择根对象

为了验证这一点，我们又手工编写了一版优化后的 SQLx 查询。

它采用两阶段执行：

第一阶段：查询根对象

先找出符合条件的 100 个 Recording ID：

SELECT recording.id
FROM recording
WHERE EXISTS (
    SELECT 1
    FROM recording_work_relation relation
    WHERE relation.entity0 = recording.id
)
ORDER BY recording.id DESC
LIMIT 100;

第二阶段：只处理这些根对象的关联

然后把第一阶段得到的 ID 作为参数传给第二个查询：

WITH ranked AS (
    SELECT
        relation.*,
        row_number() OVER (
            PARTITION BY relation.entity0
            ORDER BY relation.link_order ASC, relation.id DESC
        ) AS rn
    FROM recording_work_relation relation
    WHERE relation.entity0 = ANY($1)
)
SELECT ...
FROM ranked
JOIN link ...
JOIN link_type ...
JOIN work ...
WHERE ranked.rn <= 10;

窗口函数仍然存在，但它只对已经选中的 Recording 所对应的 Relation 进行排名。

查询结果没有变化，耗时却从 5871.169 ms 降到了 2.469 ms。

这说明 SQLx 本身没有性能问题。只要开发者明确写出正确的执行方案，SQLx 同样可以非常快。

真正的问题是：应用开发者是否应该在每一个类似场景里，亲自发现、实现并维护这种优化？

TeaQL 如何表达同一个请求

TeaQL 是一个模型驱动的应用运行时。它从语义模型生成类型化的查询 API、已加载状态表达式和受治理的图写入 API。

它目前可以面向 Rust、Java、TypeScript、Go、Swift、.NET 和 Python 生成相应的语言 API。

在 TeaQL 中，应用代码声明的是业务请求的形状。简化后可以理解为：

Q::recordings()
    // 只选择存在 Work 关联的 Recording
    .which_have_work_relations()

    // 加载 Recording 的 Work 关联
    .select_work_relations_with(
        Q::recording_work_relations()
            .select_link()
            .select_link_type()
            .select_work()
            .order_by_link_order_asc()
            .order_by_id_desc()
            .limit(10)
    )

    // 根对象按 ID 倒序，只取 100 条
    .order_by_id_desc()
    .limit(100)

    // 保留查询意图和操作目的
    .comment("加载 MusicBrainz Recording-Work 图")
    .purpose("展示有界的 Recording-Work 明细")

    .execute_for_list(&context)
    .await?;

以上代码是为了说明请求结构而做的简化示意，完整可执行版本可以在公开的基准仓库中找到。

这里最重要的并不是 Rust API 的具体命名，而是 TeaQL 能同时获得这些信息：

• 根对象最多 100 条；
• 每个根对象的 Relation 最多 10 条；
• Relation 有明确的排序方式；
• 只需要加载被引用的 Link、LinkType 和 Work；
• 查询需要继承租户、权限、版本和审计策略；
• 查询携带 comment 和 purpose 等可观察性信息。

有了这些语义，运行时就可以先选择根对象，再把关联查询限定在这些根对象之内。

应用代码不需要退回手写 SQL，也不需要自己维护两条查询之间的语义一致性。

代码量并没有出现“魔法般”的减少

我们还统计了三种实现中用于声明和执行查询的非空代码行数。

连接池初始化、计时、结果校验和报告代码没有计入；应用直接持有的 SQL 文本则计入代码量。

这个数字并不夸张，TeaQL 也没有通过代码高尔夫制造一种“只需一行”的错觉。

它完整展开后的查询，与直观 SQL 的代码量基本相当。

区别主要在于这些代码表达和保留了什么：

• 优化后的 SQLx 需要维护两条 SQL；
• 应用负责传递根对象 ID；
• 应用负责数组参数绑定；
• 两个查询阶段必须使用一致的过滤条件；
• 开发者还要自己组装类型化对象图。

TeaQL 则在同一个请求中声明一次根对象边界、关联边界和治理语义，由运行时负责将它们转化为相应的执行步骤。

所以这里的优势不是“代码更短”，而是减少需要由应用开发者手工维护的执行细节。

性能只是问题的一半

有经验的 SQL 开发者完全可以写出 2.469 ms 的 SQLx 方案。这次实验已经证明了这一点。

更值得关注的问题是：每一次手工优化都会增加新的策略执行点。

例如，在两阶段查询中：

• 第一条查询可能包含租户条件，第二条遗漏了；
• 根对象应用了权限范围，子对象却没有；
• 一边应用了软删除或版本策略，另一边没有；
• 隐私字段屏蔽、审计信息和链路追踪可能在改写过程中丢失。

当 AI 编程工具参与查询优化时，这类问题会更加隐蔽。生成的 SQL 可能确实更快，却在第二阶段意外加载了其他租户的子对象。

TeaQL 的目标并不是阻止优化，而是让两个查询阶段继续处于同一个受治理的执行模型中。

性能优化可以由运行时完成，但租户隔离、授权范围、版本策略、加载状态以及操作意图不能因此丢失。

“一个 SQL”不一定比“多个 SQL”更高效

这个实验也说明，单纯用查询次数评价性能是不够的。

“一次数据库往返”听起来通常优于“两次数据库往返”，但一个看起来很漂亮的单语句查询，可能让数据库处理数百万条与当前页面无关的数据。

相比之下，两条范围明确的查询可能只处理几百条记录。

因此，更有意义的问题不是：

这个功能执行了几条 SQL？

而是：

数据库为完成这个业务请求，实际做了多少工作？

查询次数只是成本的一部分。参与扫描、连接、排序和排名的数据量，往往更重要。

这次基准证明了什么

它证明了两件事情。

第一，业务 API 中的语义信息可以帮助运行时避免大量无效的数据库工作。

第二，根对象数量、关联数量和排序规则等业务边界，如果能在执行计划形成之前被保留下来，就可能产生非常显著的性能差异。

它没有证明什么

这次实验并不意味着：

• TeaQL 的 PostgreSQL 驱动天然比 SQLx 快；
• 所有窗口函数都很慢；
• 多条 SQL 永远优于一条 SQL；
• 2378 倍可以推广到其他数据集、硬件、索引或数据库；
• TeaQL 在所有场景中都比 SQLx 快 2378 倍。

更准确的结论是：

直观的 SQLx 查询为了返回当前页面所需的 103 条 Relation，对约 270 万行数据进行了排名。先应用业务边界，再执行窗口排名后，绝大部分工作都消失了。

TeaQL 的价值不在于拥有一个“更快的数据库驱动”，而在于让正确的边界可以被声明、类型检查、复用，并在统一的治理模型中执行。

如何复现实验

完整的测试代码和证据保存在公开仓库中：

https://github.com/teaql/teaql-runtime-benchmark

其中包含四组相关测试：

• B001：Rust TeaQL、Diesel 和 SeaORM 在 MusicBrainz 上的类型化图查询；
• B002：PostgreSQL 和 DuckDB 上的原生 JDBC 测试；
• B003：Java TeaQL 在 PostgreSQL 和 DuckDB 上的测试；
• B004：本文使用的两种 Rust SQLx 查询方案及正确性校验。

B004 保存了数据来源、查询结构、运行环境、预热次数、测量结果、返回数量和校验值，还包含一个可执行的代码行数统计工具。

2378 倍是一个真实、可复现但适用范围明确的结果。

更广泛的 TeaQL 主张并不是“永远比 SQLx 快”，而是：

让好的执行方案成为可声明、类型化、可复用且受治理的业务查询，而不是散落在应用中的一次性手工优化。

英文原文：

https://teaql.io/blog/teaql-2000x-obvious-sqlx-query/

文章是 C++ 开发者视角的内存实验笔记，对照 C++ virtual functions / CRTP 与 Rust 的 monomorphization、dyn Trait。代码与实验在 GitHub 仓库 sofiabelen/rust-vtables-for-cpp-programmers。

静态分发下，编译器为每个具体类型生成函数副本，运行时无额外开销，但类型须在编译期已知。空结构体在 Rust 中是 ZST，size_of 可为 0；身份由所有权与借用检查跟踪，不依赖“对象至少 1 字节”的地址约定。debug 下本地 ZST 可能占占位地址，release 下地址可折叠，编译器不对 ZST 地址作保证。

动态分发使用 &dyn Draw：普通引用约 8 字节，trait object 约 16 字节，是 data 指针加 vtable 指针的宽指针；同类型实例共享同一 vtable。调度策略在调用点选择：&Circle 静态，&dyn Draw 动态，vtable 不嵌在对象内。一个类型实现多个 trait 时，每个 (Type, Trait) 对有独立 vtable。可 dyn 的 trait 需满足 object safety，例如方法不能返回 Self、不能带泛型参数。

原文链接：https://sofiabelen.github.io/projects/visualizing-rusts-vtables-how-dyn-trait-works-in-memory/

GSim-RS：体积毛坯 G-code 仿真

GSim-RS 是用 Rust 写的 G-code 仿真器，面向立式 CNC 铣床的 Fanuc 风格 G-code。解析并解释 G-code，维护机床状态，并对刀路与切削做体积仿真。新版本支持立方体毛坯体积仿真，毛坯与刀具尺寸可通过程序 JSON 配置；仿真支持环绕、平移、缩放，以及等距/顶视/前视/右视切换。

架构拆成解析、解释、几何构建、仿真渲染与机床状态渲染。GUI 用 WGPU 在主线程做 G-code 解析、执行与仿真渲染，TUI 用 Ratatui 在另一线程显示活动机床状态。线程间按数据类型分别用 Arc<Mutex>（可丢弃更新）和 mpsc::channel（必达）通信。体积仿真对每帧做部分 GPU buffer 更新，避免整块 stock 重传；内向体素面启动时隐藏，邻接体素被切掉后再显露。可 cargo install gsim-rs 安装。

原文链接：https://github.com/navrajkalsi/gsim-rs

shotdock：Wayland 截图录屏与窗口装帧

shotdock 是面向 Wayland 的截图与录屏工具，带窗口装帧和可选浮动 dock，支持 Hyprland、Sway、River、Niri 等合成器。区域/窗口 snip 基于 slurp，可对截图加圆角、高斯阴影、macOS 风格标题栏和渐变画布；也支持 shotdock frame <file> 对已有图片离线装帧。

功能还包括区域选择时冻结屏幕（hyprpicker）、60 FPS H.264 录屏（wf-recorder，监视器/窗口/区域）、OCR 抽文字到剪贴板（tesseract），以及可选的 GTK4 LayerShell 浮动工具栏。可通过 AUR、GitHub Release 二进制或 cargo build --release 安装；依赖 grim、slurp、ImageMagick、wl-clipboard 等。

原文链接：https://github.com/sirrryasir/shotdock

jsonquery_gui：egui 大 JSON 多方言查询

jsonquery_gui 是用 Rust 与 egui/eframe 写的原生桌面应用，用于浏览和查询较大 JSON：拖入文件或粘贴内容后，可用 jq、JSON Pointer、JSONPath 或 JMESPath 查询。jq 通过内嵌 jaq 解释器执行，不 shell 到外部进程；查询可流式输出且可取消，大整数按字节精确往返，并支持 NDJSON。

界面提供源文档与结果的树视图/原文视图切换、搜索、右键复制节点路径或保存节点；Linux 与 Windows 有预编译包，Linux 另有 Homebrew tap。当前 Phase 1 为全量内存解析，适合中小文件；多 GB 级需尚未实现的 Phase 2 内存映射懒解析索引。MIT 许可。

原文链接：https://github.com/nujufas/jsonquery_gui

From Rust中文社区 Mike

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区

OpenVMM 是微软用 Rust 写的开源跨平台 VMM（Virtual Machine Manager），MIT 许可，仓库为 microsoft/openvmm。它既可在 OpenHCL paravisor 中作为客户机内执行环境组件，也可作为宿主机上的传统 VMM。自 2024 年开源以来，社区已有 100+ 贡献者与 200+ forks，Intel 与 Arm 等持续贡献。

跨平台方面增强了 MSHV 后端的 aarch64 支持，并改进 KVM 虚拟化正确性。设备模型新增 Arm VM 的 SMMUv3 仿真、CXL 仿真、PCIe NUMA/ACS 暴露、现代 VFIO 直通接口，以及 NetVSP 网络的完整 VLAN 支持。机密计算上，Intel TDX 机密 VM 在 Azure 的 paravisor 支持已 GA，CPU/内存密集负载下开销约从 3% 降到 1%；Arm CCA Realm 基础使能已合入，AMD SEV-SNP 持续优化。宿主支持 Linux / Windows / macOS，后端包括 MSHV、WHP、KVM、hypervisor.framework，架构覆盖 x64 与 AArch64。文档站点：https://openvmm.dev

原文链接：https://techcommunity.microsoft.com/blog/windowsosplatform/the-openvmm-project/4547237

p2pmux：多用户点对点终端复用器

p2pmux 是面向 macOS 与 Linux 的点对点终端复用器。每个 pane 是开启者机器上的真实 PTY，参与者可带着自己的环境、密钥与工具加入同一会话，并 hop 到他人 pane，而不是 SSH 进同一台机器。连接基于 iroh 1.0，端到端加密，必要时经 relay；标签栏可显示 direct / relayed 延迟。

交互接近 Zellij：Ctrl+P 管 pane、Ctrl+T 管 tab；Ctrl+O 打开 inbox，汇总会话内各机器上检测到的 coding agent。上限约 8 名成员、9 个 tab、每 tab 8 个 pane。协调者笔记本合盖后，其他机器上的 pane 继续跑；约五分钟后由最早加入的存活节点接管。可用 curl -fsSL https://p2pmux.com/install.sh | sh、Homebrew 或 cargo install p2pmux --locked 安装。join code 等同密码，需按信任模型分享。

原文链接：https://github.com/pelazas/p2pmux

PurRDF 1.0.0：一次实现的跨语言 RDF 1.2 引擎

PurRDF 是用 Rust 实现一次、再带到 Python、WebAssembly/JavaScript 与 C 的 RDF 1.2 工具集，目标是同一图在各语言中语义一致。支持 Turtle、TriG、N-Triples、N-Quads、RDF/XML、TriX、HexTuples、JSON-LD、YAML-LD；含 SPARQL 1.1 与部分 1.2、SHACL、ShEx、entailment、确定性序列化/规范化、内容寻址 dataset pack 与 GTS 传输。

在 Rust 宿主上，SPARQL 还可做确定性 BM25 全文检索、基于精确有理数几何的 GeoSPARQL，以及向量 kNN；作者称这三类常要旁挂 PostgreSQL 的能力可在同一数据集内完成。工作区刻意无 Cargo feature flags，避免条件编译造成语义分叉。1.0 起按常规语义化版本发布；MIT OR Apache-2.0，覆盖约 21 个 Rust crate 以及 PyPI 与 npm。优化后的 wasm 约 11.1 MB。

原文链接：https://github.com/Blackcat-Informatics/purrdf

MiniPdf：无 Office 依赖的 Office 转 PDF

MiniPdf 是把 Office 文档直接转为 PDF 的轻量库与 CLI，运行时不依赖 Microsoft Office、LibreOffice、Adobe Acrobat 或 COM。面向容器、serverless、CI 与跨平台应用。Rust 实现目前为实验性，支持 XLSX / DOCX / PPTX；同仓库另有更成熟的 .NET 实现，以及 Java / Python / Node.js / Go 等实验路径。

Rust 侧可 cargo add minipdf 嵌入，或 cargo install minipdf-cli 使用命令行，例如 minipdf report.docx -o output.pdf，并支持注册自定义字体。输出 PDF 1.4；Apache-2.0。作者说明目标是实用转换而非完整还原复杂 Office 版式，复杂模板可能有差异，仓库提供视觉 benchmark 报告。

原文链接：https://github.com/mini-software/MiniPdf

From Rust中文社区 Mike

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区

Rust 1.98.1 是 1.98.0 的点版本，修复 vtable 生成中的误编译。在 1.98.0 的某些情况下，rustc 会在 trait object vtable 里写入空指针而非函数指针，导致未定义行为，可能表现为段错误或其他任意效果。

已用 rustup 安装的用户执行 rustup update stable 即可升级。相关跟踪 issue 为 rust-lang/rust#161441。

原文链接：https://blog.rust-lang.org/2026/09/03/Rust-1.98.1/

static-generics：零成本泛型静态量

static-generics 是为零成本泛型静态量提供的 crate。Rust 没有 C++ 式 generic statics，常见 HashMap<TypeId, …> 每次访问都要加锁、分配与哈希。该 crate 用内联汇编与 monomorphization 发出 per-T 存储，支持平台上访问约 1–2 条指令（lea / adrp 等）；不支持平台回退 HashMap + Mutex。

仅 Zeroable 类型可直接存放；无 Drop，跨 crate / 动态库不保证同一地址。支持 x86_64、aarch64、riscv、loongarch、powerpc、s390x 等；wasm32 需 nightly asm!()。思路参考 cynecx/generic-statics。

原文链接：https://crates.io/crates/static-generics

标准库验证竞赛：Autoharness 做到万级 harness

这是 Rust Foundation 与 AWS 关于标准库验证竞赛的进展说明。标准库约 3.4 万函数；人工约一年写出 725 个 Kani harness 后增长停滞。AWS Kani 团队的 Autoharness 在 MIR 层自动生成 16748 个 harness，其中 11970 个通过 Kani 支持的 UB 检查，989 个带完整契约。

另有 VeriFast 对 LinkedList 的分离逻辑证明。未发现未知内存安全漏洞，但修了 SIMD 移位结果、unsafe 标注、SAFETY 注释与 panic 文档等问题。约 9600 个泛型函数以及并发/原子仍是缺口。RustConf 2026 将有专场更新。

原文链接：https://rustfoundation.org/media/how-the-rust-standard-library-verification-contest-scaled-past-manual-proof-engineering/

tokio_rcu：面向 Tokio 的异步 RCU

tokio_rcu 是面向 Tokio 的 RCU 库，提供 lock-free / wait-free 的共享状态更新。核心原语 synchronize_rcu 等待 grace period 以便回收被换出的数据；高层抽象是 RcuPtr。读路径基本是一次原子指针 load，适合读多写少、延迟可预测的场景。

静止状态定义为 Tokio 的 on_after_task_poll；RCU 保护的指针不能跨 await。需启用 tokio_unstable。仓库：https://github.com/roeeshoshani/tokio_rcu

原文链接：https://github.com/roeeshoshani/tokio_rcu

From Rust中文社区 Mike

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区

FMA（fused multiply-add）是一次舍入完成 a * b + c 的浮点原语，用于高精度三角函数等。作者 Sergey "Shnatsel" Davidoff 为 fearless_simd 在无硬件 FMA 的平台上做 SIMD 仿真，按 Boldo/Melquiond 2008 年 Coq 证明算法实现后，发现 Rust 标准库 f32::mul_add / std::simd 以及 musl libc 的 fmaf（源自 FreeBSD 2005–2011 代码）在 subnormal 的 halfway rounding 上处理错误。

无 AVX2 的 x86（Firefox 硬件调查约 15%）仍需软件 FMA；作者的 SIMD 路径相对 std::simd 约快 5×。fearless_simd 已修复；compiler-builtins 补丁仍在审；musl 邮件列表已有修复讨论但尚未合并。可用 a=0x97000800、b=0x1cfff001、c=0x00010002 检查：正确结果 0x00010001，错误结果 0x00010002。

原文链接：https://shnatsel.github.io/implementing-fma-finding-bugs-in-std/

rustup 1.29.1：并行检查更新与并发装组件

rustup 是官方 Rust 工具链安装器。1.29.1 让 rustup update 先并行检查更新，component add 多个组件可并发安装；rustup-init 与部分 rustup 调用中不再隐式安装当前工具链并给出警告；rustup doc 新增 --serve，用本地 HTTP 提供文档。

在 64 位 Windows 安装 i686-pc-windows-* host 需 --force-non-host；取消安装时不再留下意外文件；修复 rustup-init.sh 在 Windows 上可能失败的问题；文案将 “target triple” 改为 “target tuple”（CLI 选项未破坏兼容）。正式支持 aarch64-pc-windows-gnullvm host。已安装用户可执行 rustup self update 或 rustup update。

原文链接：https://blog.rust-lang.org/2026/09/01/Rustup-1.29.1/

rustc_codegen_gcc #43：unwinding 做到 100%

rustc_codegen_gcc 是 rustc 的 GCC 代码生成后端，用于 LLVM 未覆盖的架构。Progress Report #43 称 unwinding 已从约 80% 做到 100%；函数/变量 attributes 从 22% 升到 60%。UI 测试通过 7699（+543），失败 21（-59）。

作者称 rustup 分发版本尚未包含该 unwinding 修复，同步问题大多已解决；还向 Rust unwind 库提交了修复。下一步计划先编译若干常用 crate，再做 crater run。赞助方包括 Futurewei、Shnatsel 与 Rust Foundation。

原文链接：https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-43

Unstruct：把 XML 批量拆成可入库的 TSV

Unstruct 是把一份或多份 XML 转成一份 UTF-8 TSV 的命令行工具，便于批量导入关系数据库。作者称该工具已处理数十亿条 XML CDR（通话详单）。通过 parser 配置选择输出列、recording 元素、过滤器、属性与命名空间；每个匹配的 recording 生成一行，嵌套 recording 继承外层值。

批处理 fail-fast：全部成功后原子写入输出，失败不发布部分结果。MIT 许可，仓库提供 BAG/CDR/FTP/统计等示例。

原文链接：https://github.com/Roenbaeck/unstruct

From Rust中文社区 Mike

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区

0.5.0 把媒体桥接、转码、混音、录音统一到全新引擎上：

• 呼叫建立时延 ~6.4 ms（端到端），较上一代媒体层快 2.7 倍；
• 同编解码通话走零拷贝 fast-path 中继，单路仅 ~0.14% 核 / ~0.57 MB；
• WebRTC 与传统 SIP/RTP 互通是原生能力：800 路跨传输中继 0% 丢包，500 路 Opus↔PCMU 实时转码同样 0% 丢包；
• 18,000 通电话压力下内存平坦无泄漏，全程无序列/时间戳跳变——没有音频毛刺。

2. 5000 路并发全录音压测：0% 丢包，不到 4 核

这不是实验室数字，是真实场景（CPS=200 呼叫风暴 + 全程立体声录音 + MySQL CDR）的完整回归：

完成率 4943/5000 接听、100% 进展、0.00% 丢包，任务与话务对象全部回收，无泄漏。通话进行时数据库几乎空闲——容量规划简单到可以按 每路录音 ≈ 0.08 核 估算，线性扩展，16 核机器理论可扛 16000+ 路并发。

3. 队列与呼叫中心能力进入社区版

排队/ACD 是社区核心能力，0.5.0 补齐了生产级呼叫中心的最后几块拼图：

• 技能组路由与升级策略（escalation plan）：按技能匹配坐席，等待超时自动升级；
• 并发拨打：多个坐席同振，先接先得，杜绝坐席漏接；
• 主管四件套：listen（监听）/ whisper（耳语）/ barge（强插）/ takeover（接管），全程走 RWI 一条命令；
• 坐席签入签出、话后处理（wrapup）、排队轨迹追踪一应俱全。

4. RWI 实时控制面进化：这是给 Voice Agent 的遥控器

RWI 是 RustPBX 的实时控制协议——JSON over WebSocket，延续了 Asterisk AMI 的 action/event 模型，但去掉了所有历史包袱。0.5.0 中它覆盖了更完整的通话生命周期：

• 早期媒体即可录音（record.start 支持媒体阶段启动，含回铃音阶段）；
• 盲转 REFER 的 B2BUA 兜底：对端不支持 REFER 时自动降级为桥接转接，转移不再丢通话；
• 跨会话主管接管、双向 PCM 实时音频流（voip_bridge）、会议 create/add/remove/mute/destroy 命令族。

配合 HTTP Router 的入呼 webhook，一套接口完成"接听、放音、转人工、录音、监控"全流程。

5. 实时转写与预测外呼：AI 场景的一等公民

• 实时转写 SSE：GET /cc/calls/{call_id}/transcript，主/被叫双路独立 ASR 流，采用 Deepgram 兼容流式协议（16 kHz PCM / 20ms 帧）；懒启动设计——有人订阅才启动，无人订阅自动停止，不改变媒体路径，与录音、监听和平共处；
• 离线转写：本地 SenseVoice 引擎，通话结束即出全文记录，数据不出内网；
• 预测外呼 SSE：POST /ami/v1/outbound/dial 一个 HTTP 请求发起呼叫，标准 RWI 事件（created → ringing → answered → bridged）通过 SSE 实时回流，on_answer 可直接挂接后续动作。

ASR 结果、DTMF、通话状态事件同步推送——你的语音机器人只需要一个 WebSocket 连接。

传统 PBX 该有的底座，一样不少

RustPBX 不是只会跑 AI 的玩具——作为一台可以接生产话务的 PBX，基础功全部到位：

路由表与中继管理

• 静态路由规则引擎：正则匹配、号码改写、按优先级排序，Web 控制台可视化编辑，0.5.0 新增路由策略栈视图与运行时排序调整；
• SIP 中继（Trunk）完整管理：注册型/对等型中继、健康检查、故障自动切换、自定义 SIP 头透传，多中继负载均衡；
• 静态路由打不了的复杂决策，自动回落到 HTTP 动态路由（fallback_to_static 双向兜底）。

IVR 引擎

• 内置 IVR 流程引擎：DTMF 菜单分支、放音收号、转接动作用统一 ActionNode 协议描述，步骤式（step mode）流程可以交给外部 Provider 逐步决策——你的 Python 服务就能当 IVR 大脑；
• IVR Exec：通话进行中随时插入 IVR 流程，播完自动返回原通话；
• 会话级 IVR Fallback：流程异常自动接管播报，TTS 音频缺失自动回退，不会让用户听到死寂。

呼叫转移

• 盲转、协商转（attended）原生支持；对端不支持 REFER 时自动降级为 B2BUA 桥接转接，转移永不丢通话；
• 队列转接携带业务参数（UUI/自定义头），坐席接手时上下文不丢。

安全配置

• ACL 访问控制：内联规则 + 规则文件目录双模式，支持热更新；
• DoS 防护：CPS（每秒呼叫数）限流、并发通话数上限、SIP worker 线程隔离，恶意洪水打不穿信令面；
• URI 合法性校验、in-dialog 认证缓存、SBC/可信代理链支持（X-Forwarded-For 式的多跳场景）；
• TLS/SRTP + ACME 自动证书、RBAC 权限体系、AMI API IP 白名单、/metrics 端点 Bearer Token 保护。

数据库与存储：一行 URL，录音直传 S3

• SQLite（默认，零依赖起步）/ PostgreSQL / MySQL 三选一，改一行 database_url 即完成切换；话单库还可与主库分离，话务高峰互不干扰——实测 5000 路并发全录音场景数据库稳态 QPS 仅 2–4；
• 录音默认就能直传 S3：type = "s3" 通话结束自动上传任意 S3 兼容对象存储，本地先落盘、上传确认成功才清理，失败自动留痕标记，网络抖动不丢录音；CDR JSON、SIP 信令 JSONL 同样支持直传 S3/HTTP——一个 bucket 收齐全部话务数据；
• 录音策略精细可配：文件名模板（{caller}/{callee}/{timestamp}）、按方向与主被叫黑白名单决定录谁不录谁（比如 911 免录）、回铃阶段即可开录；
• 节点无需共享存储：录音和话单都进对象存储，多副本部署天生无状态。

TLS 与证书：全栈加密开箱即用

• 管理台/API/Webhook 内置 HTTPS 监听，配一对证书路径即可；
• SIP 加密（SIPS，TLS 5061）与 WebRTC（WSS）原生支持，出站连接可校验对端证书链；
• ACME 自动证书：Let's Encrypt 自动签发与续期，certbot 定时任务可以删了。

集群：多节点组网，配置即声明

• [cluster] 配置里列出所有节点即完成组网；
• 会话注册表实时回答"这通电话在哪个节点"，控制请求自动转发到所属节点，不必关心话务落在谁身上；
• 心跳保活 + 宕机节点会话回收窗口，节点掉线话务可重新调度；
• 集群级配置一键下发刷新全部节点，控制台日志查看器可直接切换远端节点。

线上日志与诊断：不用 SSH 的排障

• 控制台内置日志查看器：实时跟随新输出、按节点切换、行数选项与一键复制；日志文件按天/小时自动轮转；
• 诊断工具箱：活跃对话一览、中继测试（发起真实测试呼叫 / OPTIONS 探测）、路由评估器（输入主被叫号码立即预览路由决策结果，改路由前先演练）、分机注册定位查询；
• AMI API 健康检查与原始 dialog 检视，配合 /healthz 探针与 Prometheus /metrics 全指标暴露。

运维体验

• 配置热重载：POST /reload/trunks、/reload/routes、/reload/acl、/reload/queues、/reload/ivr——按对象粒度热更新，不重启进程、不挂断进行中的通话；路由/中继/ACL 还支持数据库配置模式，控制台改完即用；
• 优雅关机：SIGTERM 后先排水再退出，打完最后一通电话才下线；
• SipFlow 可视化排障：Web 控制台里直接查看每通电话的完整 SIP 信令流与 RTP 质量统计，录音在线回放、WAV 导出，JSONL 一键归档——sngrep 可以退休了。

我写了 rsvm：

https://github.com/rsvm-sh/rsvm

它从 static.rust-lang.org 下载官方工具链，校验 SHA256，装到 ~/.rsvm/versions/ 下面。可以同时装着好几个版本；切换时只改当前这个终端的 PATH，别的窗口不受影响。也不会调用 rustup default。

多版本

每个版本单独一个目录，互不覆盖：

~/.rsvm/versions/1.85.0/
~/.rsvm/versions/1.98.0/
~/.rsvm/versions/1.100.0-nightly-2026-08-30/

rsvm install 只往里加，不会把已经装好的删掉。rsvm list 看装了哪些。rsvm uninstall 1.85.0 只删这一个，缓存里的安装包也会清掉。正在用的版本不能删，先 rsvm use 切走再卸。

rsvm install stable
rsvm install beta
rsvm install nightly         # 目录名会带上日期
rsvm install 1.85.0

rsvm list
rsvm current
rsvm which 1.85.0
rsvm uninstall 1.85.0

stable / beta / nightly 安装时取该通道当时的最新版。rsvm alias default 1.85 表示默认用已安装的最新 1.85.x，新开终端会跟这个 default。

切换版本

rsvm use <version> 把这个版本的 bin 放到当前终端 PATH 最前面。已经打开的其他终端不会跟着变。

rsvm use stable
rustc --version

rsvm use 1.85.0
rustc --version

rsvm use system              # 当前终端不再走 rsvm，改用系统里的 rustc

不想切整个终端，只想用某个版本跑一条命令：

rsvm run 1.85.0 cargo test
rsvm-exec 1.85.0 cargo build

项目里可以放一个 .rust-version 指定版本。命令不写版本号时，rsvm install、rsvm use、rsvm-exec -- 会从当前目录往上找最近的这个文件。

echo 1.85.0 > .rust-version
rsvm use
rsvm-exec -- cargo test

这个文件只有 rsvm 会读。Cargo 和 rust-analyzer 认的是 rust-toolchain.toml。

切版本只作用于当前终端，不会改全局默认，也不会调用 rustup default。

现状

• v0.1.0，MIT
• bash / zsh，需要 curl 和 tar
• 暂时没有 Windows 和 fish
• 装下来的是官方这套：rustc、cargo、rustdoc、std

安装

curl -o- https://raw.githubusercontent.com/rsvm-sh/rsvm/v0.1.0/install_sh.sh | bash
source ~/.zshrc   # 或 ~/.bashrc
rsvm help

欢迎提意见、开 issue 和 PR。

仓库： https://github.com/rsvm-sh/rsvm 许可证： MIT

wedb_embed : Redis 兼容的嵌入式 LSM-Tree 磁盘数据库引擎

嵌入式数据库引擎，提供 Redis 兼容数据结构与接口，基于 fjall LSM-Tree 存储引擎构建。

• 磁盘 I/O 影响： WeDb 为磁盘数据库，性能表现与底层存储硬件 I/O 吞吐紧密相关。 在 Apple M2（NVMe SSD）实测综合性能约为 Redis 的 40 倍； 在 GitHub Actions（Linux 云端虚拟磁盘）实测综合性能约为 Redis 的 20 倍。 两者的性能倍率差异主要源于底层磁盘硬件的 I/O 吞吐与读写延迟差异。

• 内存预算控制： 常驻内存由 cache_size（默认 512MB 块缓存）与 max_memtable_size 参数控制， 不随磁盘数据量线性膨胀。

为什么需要嵌入式 Redis 引擎

如同 SQLite 之于 MySQL/PostgreSQL，wedb_embed 是 Redis 生态的嵌入式磁盘数据库引擎。

在传统关系型数据库体系中，MySQL 采用独立服务端守护进程与网络套接字通信架构； SQLite 则以进程内嵌入式库直接将数据持久化于本地磁盘文件，无需独立守护进程与跨进程调用。

在键值与复合数据结构领域，传统 Redis 采用独立守护进程与物理内存常驻架构。 在单机部署、边缘计算、命令行工具与微服务场景中，该架构存在以下系统层面的瓶颈：

• 进程间通信与协议开销： 每次数据读写均需经过序列化、操作系统套接字缓冲区、进程上下文切换与 RESP 协议解析。 即便在本地主机通信，套接字往返延迟通常也在 20~50 微秒区间，并持续消耗 CPU 周期。

• 物理内存成本与容量边界： Redis 将业务数据与内部指针常驻于物理内存中。 当数据规模增长至数十 GB 时，内存硬件成本上升，且严格受限于单机物理内存容量。 开启 AOF 或 RDB 持久化时，写时复制（Copy-on-Write）机制可能导致内存翻倍。

• 部署与守护运维复杂度： 独立进程需要额外的进程守护、端口监听、配置同步与健康检查， 增加了软件交付与运维的维护负担。

wedb_embed 将存储引擎直接编译并运行在应用程序进程空间内：

• 进程内直接调用： 所有 Redis 兼容数据操作通过 Rust 函数直接调用， 避免了套接字 I/O、系统调用与跨进程上下文切换。 在同等硬件下，核心指令的 P95 延迟降低至纳秒与微秒级。

• LSM-Tree 磁盘持久化与内存预算控制： 数据经过 LZ4 块压缩存储于本地磁盘文件。 常驻内存不随数据总量线性增长，由 LSM-Tree 参数严格控制：

  • cache_size（默认 512MB）：全局共享的 SSTable 块缓存上限，用于缓存热点数据页；
  • max_memtable_size（数据分区 64MB / 元数据分区 32MB）：内存写缓冲上限，达到阈值后自动异步刷盘生成不可变 SSTable；
  • with_kv_separation（大 Value 分离阈值 4KB）：大对象直接写入独立 Blob 文件，降低写放大与内存占用。 在 5GB 结构化数据实测中，Redis 物理内存占用达 4814 MB（RSS）， wedb_embed 常驻内存为 334 MB（降低 93%），物理落盘体积由 Redis AOF 的 7652 MB 压缩至 1180 MB（减少 85%）。

• 16 种 Redis 兼容数据模型： 在底层键值引擎之上，支持 String、Hash（支持字段级 TTL）、List、Set、ZSet、Bitmap、JSON、 Bloom/Cuckoo 过滤器、TimeSeries、Geo、HyperLogLog、TDigest、SortedInt、Stream、全文检索与 HNSW 向量检索。

• 多租户与多库物理隔离： 原生支持 $2^{64}$ 个独立租户与数据库。 命名空间（ns）与数据库（db）传入 None 时自动分配递增编号并创建新实例。

• 崩溃一致性保障： 基于预写日志 WAL 与跨分区原子批处理 WriteBatch，保障断电与异常退出场景下的数据完整性。

快速上手

添加依赖

cargo add wedb_embed

基础用法与多租户

use anyhow::Result;
use wedb_embed::{Fjall, WeDb};

fn main() -> Result<()> {
    // 打开存储引擎并初始化 WeDb 实例
    let engine = Fjall::open("./data/quickstart_db")?;
    let wedb = WeDb::new(engine);

    // 租户命名空间与多库切换（ns 传入 None 创建新命名空间，db 传入 None 创建新数据库）
    let default_db = wedb.ns(0)?.db(0)?; // 默认命名空间 (0) 与默认数据库 (0)
    let tenant_ns = wedb.ns(None)?;      // 创建新命名空间 (ns_id >= 1)
    let db = tenant_ns.db(None)?;        // 租户下创建新数据库 (db_id >= 1)

    // 字符串读写 (String / KV)
    db.set(b"site", b"webc.site", &[])?;
    let val = db.get(b"site")?;
    assert_eq!(val.as_deref(), Some(&b"webc.site"[..]));

    // 哈希表与有序集合等数据结构操作
    db.hset(b"user:100", &[(b"name".as_slice(), b"Alice".as_slice())])?;
    db.zadd(b"rank", &[(100.0, b"player1".as_slice())], &[])?;

    // 流式遍历活跃命名空间与数据库
    for ns in wedb.iter(0) {
        println!("Namespace: {}", ns.id());
        for db_id in ns.iter(0) {
            println!("  DB: {db_id}");
        }
    }

    // 级联删除与目录注销 (rm)
    db.rm()?;        // 级联删除并注销当前数据库
    tenant_ns.rm()?; // 级联删除并注销该命名空间下的全部数据库

    Ok(())
}

点此查看完整示例代码（包含 16 种数据结构与多租户详细用法）

性能与资源实测对比

<+ ./bench/zh.md >

存储架构与编码设计

graph TD
  Client["应用业务代码 (Rust API)"] --> WeDb["WeDb 数据库引擎"]
  WeDb --> NS["Namespace 租户句柄<br/>(零堆分配结构体)"]
  NS --> DB["Db 数据库句柄<br/>(作用域隔离)"]

  subgraph KeyComposer["键编排与紧凑编码 (KeyComposer)"]
    Tag["1 字节紧凑标签 (#[repr(u8)] KeyTag)"]
    OPPV["OPPV 保序变长整型 (1~9 字节)"]
    SmallKey["SmallKey 64B 栈上缓冲 (零堆分配)"]
    Subkey["SubkeyComposer 前缀内存复用"]
  end

  subgraph Engine["存储引擎与事务层 (LSM-Tree Core)"]
    Batch["DbBatch 原子批处理 (跨分区 WAL)"]
    Catalog["Catalog 元数据目录与 $2^{64}$ 租户索引"]
    Blob["KV 分离引擎 (大 Value Blob 存储 >= 4KB)"]
  end

  subgraph Storage["Fjall LSM-Tree 双分区存储引擎"]
    DataKS["data 数据分区<br/>(String 数据、复合子键与 Blob 引用 ｜ 8KB 块 ｜ LZ4 压缩)"]
    MetaKS["meta 元数据分区<br/>(结构元数据、版本号与租户 Catalog ｜ 4KB 块 ｜ 100% 内存哈希索引)"]
  end

  DB --> KeyComposer
  KeyComposer --> Engine
  Engine --> DataKS
  Engine --> MetaKS
  Engine --> Blob

双分区物理存储与前缀编排

• 双分区物理架构 (data / meta)：

  • 数据分区 (data)： 存储 String 原始值、复合结构子键与大 Value Blob 引用。 采用 8KB 块大小与 LZ4 块压缩，配置大对象 KV 分离（大 Value 写入独立 Blob 文件以降低写放大）。
  • 元数据分区 (meta)： 存储复合结构元数据（KeyMeta）、版本计数器与 Catalog 租户目录。 采用 4KB 块大小与内存哈希索引，保障元数据点查的亚微秒级延迟。

• 1 字节紧凑标签 (KeyTag)： 复合结构元数据与子键前缀采用 #[repr(u8)] KeyTag 编码（如 \x01[key]）， 避免字符串标签带来的存储与解析开销。

• 作用域前缀与多租户隔离： 多租户与多数据库统一由 KeyComposer 编码为 \x00[oppv(ns_id)][oppv(db)] 物理前缀， 支持 $2^{64}$ 个租户与数据库的隔离存储。

保序变长整型编码

• 数据库编号与租户 ID 采用 OPPV（Order-Preserving Prefix Varint） 编码：
  • 数值 $0 \sim 127$ 仅占用 1 字节，较固定 8 字节大端序降低空间占用；
  • 编码后的字节序与原始数值大小顺序一致：$\forall a < b \implies \text{encode}(a) < \text{encode}(b)$，支持底层直接进行范围扫描。

租户目录编排与级联注销

• 命名空间与数据库采用 u64 编号体系，ns 或 db 传入 None 自动分配全局递增 ID。
• 通过 Catalog 目录（\x00\x71[oppv(ns_id)][oppv(db_id)]）持久化维护激活索引。
• 支持数据库级与租户级的级联删除与注销（rm()），清理数据并更新 Catalog 目录索引。

内存友好流式迭代

• WeDb::iter(&self, begin: u64) -> Namespaces： 基于 Catalog 前缀流式扫描已激活的租户命名空间列表， 支持从指定 begin 起始偏移开始扫描，辅助内存复杂度为 $O(1)$。

• Namespace::iter(&self, begin: u64) -> Dbs： 基于 Catalog 前缀流式解析该租户下所有已激活的数据库编号。

运行时生态与线程模型设计

wedb_embed 针对基于 Linux io_uring 的 Thread-per-Core（单线程单核心）异步运行时（例如 compio）进行协同设计， 利用单核独占、无共享状态与绑核特性发挥硬件缓存局部性。

graph LR
  subgraph CompioModel["compio 线程模型 (Thread-per-Core)"]
    direction TB
    C1["CPU 核心 0 (工作线程 0)<br/>绑定物理核心"] --> S1["栈缓冲 SmallKey (64B)<br/>L1/L2 缓存命中"]
    C2["CPU 核心 1 (工作线程 1)<br/>绑定物理核心"] --> S2["栈缓冲 SmallKey (64B)<br/>L1/L2 缓存命中"]
    S1 --> IO1["同步调用 / io_uring<br/>无工作窃取 ｜ 无上下文切换"]
    S2 --> IO2["同步调用 / io_uring<br/>无工作窃取 ｜ 无上下文切换"]
  end

  subgraph TokioModel["Tokio 工作窃取模型 (Work-Stealing)"]
    direction TB
    T1["工作线程 A"] <-->|"跨核任务窃取<br/>L1/L2 缓存失效 ｜ NUMA 迁移"| T2["工作线程 B"]
    T1 --> ST["堆分配状态机 (Send + 'static)<br/>互斥锁竞争 ｜ 破坏栈生命周期"]
    T2 --> SB["阻塞线程池切换<br/>线程上下文切换 ｜ 延迟放大"]
  end

一线程一核心架构设计

• 栈上生命周期与零堆分配： 物理键构建采用 SmallKey 64 字节栈缓冲与 SubkeyComposer 前缀复用。 在单线程单核心模型下，执行上下文保持在当前 CPU 核心的栈帧内， 无需向全局堆分配器（如 jemalloc 或 glibc malloc）申请内存，避免了多线程堆分配锁争用。

• CPU 缓存行局部性： 工作线程与物理 CPU 核心静态绑定，任务执行不发生跨核迁移。 热点数据结构（LSM-Tree 内存表索引、布隆过滤器位图、Catalog 元数据缓存）常驻于当前 CPU 的 L1/L2 缓存， 避免多核缓存一致性协议广播无效化消息导致的缓存行失效。

• 无锁与轻量并发元数据： 命名空间与租户目录采用 papaya::HashMap 无锁并发哈希表，读操作无等待； 低频的元数据写操作采用 parking_lot 自适应自旋锁，在单核独占环境下自旋即完成， 不触发内核态 Futex 上下文挂起与跨核唤醒。

• 同步内嵌调用： 存储引擎 API 均为同步内存与磁盘直接调用。 在单线程事件循环中，微秒级与纳秒级查找就地执行， 与底层 io_uring 异步 I/O 配合，避免将 Future 包装为跨线程状态机。

传统多线程工作窃取运行时问题分析

在基于多线程工作窃取与 epoll 的通用异步运行时中，存在以下性能与调度开销：

• 跨核心任务窃取导致缓存失效： 调度器在工作线程空闲时跨核窃取任务。 同一请求的 Future 在 await 恢复后可能被调度到其他 CPU 核心或跨 NUMA 节点， 导致 L1/L2 缓存失效，增加访存延迟与 P99 尾部延迟。

• 破坏栈生命周期约束： 通用异步任务通常要求满足 Send + 'static 约束， 栈上分配的短期借用结构（如 &[u8] 切片、栈上 SmallKey）无法跨 await 点存活， 需重新分配至堆内存（Box / Arc / Vec<u8>），增加了堆分配开销。

• 事件循环阻塞与线程池切换： 在单线程事件循环中直接执行磁盘读取或耗时查找可能阻塞事件循环； 若转发至阻塞线程池，则引入线程上下文切换、跨线程通道传递与调度排队， 使微秒级操作延迟增加。

• 多核心内存总线争用： 多线程并发访问共享实例时，跨核心原子操作与锁争用会导致内存总线锁争用， 限制高并发下的吞吐扩展能力。

技术栈

• 开发语言：Rust Edition 2024
• 存储引擎：fjall LSM-Tree 存储引擎
• JSON 引擎：sonic-rs SIMD 指令解析
• 非加密哈希：rapidhash
• 字符串与内存：hipstr 紧凑字符串
• 并发同步：parking_lot
• 集合与位运算：roaring、memchr、crc32fast、fastrand
• 时间戳处理：coarsetime
• 数值与浮点序列化：zmij、itoa
• 枚举派生：strum
• 错误处理：thiserror

ADAR One 是挪威 Sonair 的 3D 超声波传感器产品，面向机器人与机械安全场景：发射全向超声波脉冲，多换能器接收反射并生成 3D 点云；当保护区内出现目标时，通知机器人或设备减速/停机。公司宣布 ADAR One 成为首个以 Rust 实现并完成安全认证的嵌入式系统。

团队原为 C/C++ 嵌入式背景，启动时无人正式交付过 Rust 产品。选型主要针对 C/C++ 内存与并发痛点；当时编译器安全认证尚未完成，需沿 Ferrocene 路径推进。技术负责人 Espen Albrektsen 撰文记录从语言选型、bare metal 实现到最终认证的过程与难点。

原文链接：https://www.sonair.com/journal/how-we-safety-certified-the-worlds-first-rust-implementation

Wasmi 2.0：WASM 解释器相对 1.0 约快 2.2×

Wasmi 是高效 WebAssembly 解释器，用于 IoT、插件系统（Typst、Zellij、Josh）、云主机、智能合约（Soroban、Ripple）与轻量游戏主机（Firefly Zero）等。作者 Robin Freyler 发布 Wasmi 2.0：约 8 个月聚焦执行性能的引擎大改。

在 Apple M2 Pro 上，wasmi-benchmarks 几何均值显示相对 Wasmi 1.0 约快 2.2×，并与 Wasm3、WAMR fast-interpreter、Wasmtime Pulley、Makepad Stitch 等对比。2.0 还提供 validate feature 缩小产物、稳定 fuel metering、WebAssembly deterministic profile 支持与改进 CLI。项目获 Stellar Development Foundation 自 2024-10 起赞助。

原文链接：https://wasmi-labs.github.io/blog/posts/wasmi-v2.0/

Sonora：Rust + GPUI 跨平台原生音乐播放器

Sonora 是学生团队用 Rust 与 GPUI 实现的原生音乐客户端，支持 Spotify、YouTube（可选登录）与本地曲库，并提供虚拟播放列表、收藏、同步/卡拉 OK 歌词（含本地音乐）、罗马化、库内管理、无缝播放、音量归一化、跨平台与自定义主题。

UI 受 Zed/GPUI 启发，并对 GPUI fork 做了效果与 profiling 相关补丁；作者强调相对 Spotify Desktop 更低的内存占用。macOS 可用 Homebrew cask 安装，Linux 提供 AUR 等路径。仓库当前约 95 star，版本到 0.28.1。

原文链接：https://github.com/nolight132/sonora

Rust-GB：用 Pure Rust 写出 Game Boy ROM

Rust-GB 目标是把 Rust 编译为 Game Boy ROM。早期经 SDCC / GBDK；作者现已写出 LLVM-Z80，可将 LLVM IR 直接编到 Game Boy 机器码，并据此构建 Game Boy 侧 Rust 库，从而能用 Pure Rust 编写 Game Boy 程序。

仓库提供 HAL/runtime（rust-gb、gb-rt 等）、cargo-gb 等 host 工具与示例 ROM；相关产物还包括 llvm-z80 / rust-z80。示例 sprite ROM 可下载；作者还在推进 Game Boy 硬件的 safe Rust API。GitHub 约 291 star。

原文链接：https://github.com/zlfn/rust-gb

From Rust中文社区 Mike

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区

数据库 ↔ Git ↔ SSH / SFTP ↔ 剪贴板

• GitHub：https://github.com/tools-rs/ramag
• 下载：https://github.com/tools-rs/ramag/releases/tag/v0.0.2
• 更新记录：https://github.com/tools-rs/ramag/blob/main/CHANGELOG.md

v0.0.2 主要更新

SSH 连接管理

新增完整的 SSH 管理入口，支持：

• 密码、系统 SSH 配置和密钥认证
• 解析 ssh user@host -p 2222 -i /path/to/key 命令
• 连接测试、默认目录和生产连接标记
• 多连接标签和连接搜索
• 本机加密保存密码与敏感连接参数

终端连接复用系统 OpenSSH，因此可以继续使用现有的 ~/.ssh/config、SSH Agent、密钥和 known_hosts。

内嵌终端与 SFTP 文件工作区

连接成功后，可以在同一个工作区中使用内嵌终端和远程文件浏览：

• ANSI 终端显示和常用键盘输入
• 一个连接下打开多个终端标签
• 始终保留至少一个终端，避免误关后留下空页面
• 远程目录浏览、路径导航和名称搜索
• 文本预览与编辑、日志跟随
• 文件和目录上传下载
• 覆盖确认、取消和传输进度

还可以从当前路径、目录或文件所在位置创建新终端。新终端会进入对应远程目录，不影响已有终端的运行状态。

生产连接会禁止 SFTP 上传、编辑、重命名和删除。终端命令仍由远端账号权限与服务器策略约束。

JumpServer 导入

支持保存多个 JumpServer 登录，并直接读取：

• 组织与资产树
• 已授权资产
• 资产平台和地址
• 可用的授权账号

选择资产与授权账号后，可以导入为普通 SSH 连接，继续编辑、测试和打开。未开放 SSH 协议的资产会明确提示，不会错误导入。

数据库改进

• 结果搜索支持字符串 ID 与整数 ID 双向转换。
• 内置 Base10、Base16、Base36、Base58 Bitcoin、Base58 Flickr 和自定义字符表。
• 支持带路径、超时和输出限制的外部转换器。
• 修复 MySQL SHOW WARNINGS 被识别为普通分页查询的问题。
• 数据库连接导入导出迁移到全局设置，可统一处理 MySQL、PostgreSQL、Redis 和 MongoDB。
• 编辑连接时完整回填现有参数，生产连接继续受只读保护。

Git 与剪贴板改进

Git 工作台新增明确的克隆入口，Markdown 文件默认渲染预览，并重新整理了分支、远端、Tag 和 Stash 操作。同时修复新建分支导致的界面崩溃、分栏宽度串联和部分标签无法通过 ⌘W / Ctrl+W 关闭的问题。

剪贴板仍默认关闭。启用状态、采集行为、全局热键和“清空全部历史”统一迁移到全局设置；关闭后会隐藏入口并释放全局快捷键。

macOS：⌘⇧V
Windows：Ctrl+Shift+V

本地优先与安全边界

Ramag 不要求登录账号，也不会把数据库连接、SSH 凭据、Git 仓库或剪贴板内容上传到 Ramag 服务。

• 敏感配置使用 AES-256-GCM 加密。
• 主密钥保存在 macOS Keychain 或 Windows Credential Manager。
• SSH 认证、主机校验和 Git 网络操作复用系统已有配置。
• 数据库和 SSH 生产连接会限制界面中的写操作。

Git 功能仍处于试验阶段。生产数据库操作、Git 写操作和远程终端命令仍需要使用者确认目标环境和影响范围。

下载

v0.0.2 Release：

https://github.com/tools-rs/ramag/releases/tag/v0.0.2

当前提供：

Ramag-0.0.2-macos-arm64.dmg
Ramag-0.0.2-macos-x86_64.dmg
Ramag-0.0.2-windows-x64-setup.exe
SHA256SUMS.txt

支持 macOS 12+ Apple Silicon、macOS 12+ Intel 和 Windows 10/11 x64，暂不支持 Linux。

当前 Windows 安装包尚未做 Authenticode 签名，macOS 安装包尚未完成 Developer ID 签名与 Apple 公证。请只从项目 Releases 下载，并使用同一页面的 SHA256SUMS.txt 校验文件。

从源码运行：

git clone https://github.com/tools-rs/ramag.git
cd ramag
make develop

如果你正在使用 Rust、GPUI、数据库工具或 SSH/SFTP 工作流，欢迎下载体验。遇到问题时，可以在 GitHub Issues 中附上操作系统、Ramag 版本和复现步骤；提交前请删除服务器地址、用户名、密码和业务数据。

• Issues：https://github.com/tools-rs/ramag/issues
• 源码：https://github.com/tools-rs/ramag

🔐 安全性大幅增强

• 移除 SHA-1，新增 SSH layer，支持后量子密钥交换算法 mlkem768x25519，彻底修复 SSH 安全警告
• 修复了 git clone 无法安全断开 TCP 连接的问题

⚙️ 后台管理优化

• 支持用户软删除，数据管理更灵活
• 支持用户安全更新邮箱

🚀 CI 与体验提升

• 支持 cursor-based CI 日志拉取，交互更顺畅
• UI 全面打磨，修复了多项历史遗留问题，视觉和操作更一致流畅

为什么要做这个项目: 第一点: 肯定是因为兴趣爱好, 因为我喜欢写代码, 喜欢做这个事情 第二点: 我见识过类似的各种平台, 但都是差强人意, 体验很糟糕 第三点: 的的确确我找不到工作, 失业了, 职场远远不是你想写代码那么简单, 这是一个很痛的现实, 但我必须要接受, 因为我还想继续写代码直到写不动的那一天, 可现实不允许我这样

欢迎大家下载试用，也期待大家的反馈和建议！ 🙏

关于大家关心的源代码开源问题, 目前有计划在将来进行开源, 但具体开源时间还不确定.

详细发布日志:

https://github.com/gitbundle/gitbundle/releases/tag/server-v3.5.0

Features Async-First Design: Built from ground up for async/await with Tokio integration Zero-Copy: Efficient buffer management using the bytes crate Lock-Free Buffer Pool: High-performance memory management with crossbeam Connection-Oriented: High-level connection abstractions (KcpStream, KcpListener) Protocol Compatible: Compatible with original C KCP implementation Observability: Integrated tracing and metrics support Memory Efficient: Object pooling and buffer reuse Multiple Performance Modes: Normal, Fast, Turbo, Gaming presets Installation Add this to your Cargo.toml:

[dependencies] kcp-tokio = "0.4" tokio = { version = "1.0", features = ["full"] } Quick Start Client use kcp_tokio::{KcpConfig, KcpStream}; use tokio::io::{AsyncReadExt, AsyncWriteExt};

#[tokio::main] async fn main() -> Result<(), Box> { let config = KcpConfig::new().fast_mode(); let mut stream = KcpStream::connect("127.0.0.1:12345".parse()?, config).await?;

// Send data
stream.write_all(b"Hello, KCP!").await?;

// Receive response
let mut buffer = [0u8; 1024];
let n = stream.read(&mut buffer).await?;
println!("Received: {}", String::from_utf8_lossy(&buffer[..n]));

Ok(())

} Server use kcp_tokio::{KcpConfig, KcpListener}; use tokio::io::{AsyncReadExt, AsyncWriteExt};

#[tokio::main] async fn main() -> Result<(), Box> { let config = KcpConfig::realtime(); let mut listener = KcpListener::bind("127.0.0.1:12345".parse()?, config).await?;

println!("Server listening on 127.0.0.1:12345");

while let Ok((mut stream, addr)) = listener.accept().await {
    println!("New connection from {}", addr);
    tokio::spawn(async move {
        let mut buf = [0u8; 1024];
        while let Ok(n) = stream.read(&mut buf).await {
            if n == 0 { break; }
            let _ = stream.write_all(&buf[..n]).await;
        }
    });
}

Ok(())

} Architecture ┌─────────────────────────────────────────────────────────────┐ │ Application Layer │ │ (User code using KcpStream/KcpListener) │ ├─────────────────────────────────────────────────────────────┤ │ High-Level API Layer │ │ KcpStream KcpListener │ │ (AsyncRead/AsyncWrite, TCP-like interface) │ ├─────────────────────────────────────────────────────────────┤ │ Protocol Core Layer │ │ KcpEngine │ │ (ARQ logic, congestion control, retransmission) │ ├─────────────────────────────────────────────────────────────┤ │ Common Layer │ │ KcpSegment, KcpHeader, BufferPool, Constants │ ├─────────────────────────────────────────────────────────────┤ │ Transport Layer │ │ Generic Transport trait (UDP default) │ └─────────────────────────────────────────────────────────────┘ Configuration Performance Presets // Gaming - ultra-low latency (3ms update interval) let config = KcpConfig::gaming();

// Real-time communication (8ms update interval) let config = KcpConfig::realtime();

// File transfer - high throughput let config = KcpConfig::file_transfer();

// Testing with packet loss simulation let config = KcpConfig::testing(0.1); // 10% packet loss Performance Modes Mode Update Interval Resend Congestion Control Use Case Normal 40ms 0 Yes General purpose Fast 8ms 2 Yes Low latency Turbo 4ms 1 No Maximum speed Gaming 3ms 1 No Real-time games Custom Configuration use std::time::Duration;

let config = KcpConfig::new() .fast_mode() .window_size(128, 128) .mtu(1400) .connect_timeout(Duration::from_secs(10)) .keep_alive(Some(Duration::from_secs(30))) .stream_mode(true); Examples

Run performance test server

cargo run --example perf_test_server -- 127.0.0.1:12345 gaming

Run performance test client

cargo run --example perf_test_client -- 127.0.0.1:12345

Run simple echo example

cargo run --example simple_echo Testing

Run all tests

cargo test

Run resilience tests (packet loss, reorder, concurrent connections)

cargo test --test resilience_test

Run benchmarks

cargo bench

Run with logging

RUST_LOG=debug cargo test -- --nocapture

Run clippy

cargo clippy --all-targets -- --deny clippy::all Documentation Detailed documentation is available in the doc/ directory:

Document Description ARCHITECTURE.md System architecture and design MODULES.md Module reference and APIs USAGE.md Usage guide and examples TESTING.md Testing guide Performance KCP provides significant latency improvements over TCP:

30-40% lower latency in typical network conditions Better performance on lossy networks Configurable trade-offs between latency and bandwidth Optimizations in this Implementation Actor-based lock-free architecture: KcpEngine runs in a single dedicated tokio task, eliminating Arc<Mutex<>> contention Generic Transport trait: Associated Addr type with RPITIT — zero heap allocation on hot path (no Pin<Box>) DashMap for packet routing: Listener uses lock-free concurrent hashmap on the hot path Lock-free buffer pools: crossbeam::queue::ArrayQueue for zero-allocation fast path BTreeMap receive buffer: O(log n) insertion for out-of-order packets (vs O(n) linear scan) Zero-copy segment encoding: Flush avoids cloning segments, encodes by reference Cached timestamps: Single syscall per input() call instead of 3+ Pre-allocated buffers: VecDeque::with_capacity based on window sizes, avoiding grow overhead on send burst Zero-copy packet handling with bytes crate Grouped state structs for better cache locality Configurable update intervals (3-40ms) Batch ACK processing Use Cases Gaming: Ultra-low latency for real-time multiplayer VoIP/Video: Real-time communication Live Streaming: Low-latency data delivery File Transfer: Reliable bulk data transfer IoT: Efficient communication for constrained devices Compatibility Protocol: Compatible with original C KCP Rust: Edition 2021, stable toolchain Tokio: 1.0+ License MIT License - see LICENSE file.

Contributing Contributions are welcome! Please feel free to submit a Pull Request.

Resources Original KCP Protocol KCP Protocol Documentation Tokio Documentation Benchmarks Criterion benchmarks measure engine-level throughput and latency:

cargo bench Benchmark Description engine_throughput 10/100/500 x 1KB messages engine_small_messages 1000 x 64B messages engine_large_message Single 16KB/64KB message fragmentation + reassembly Version History v0.4.0: Extract kcp-core as standalone protocol crate, restructure source layout (src/ → kcp/, flatten async_kcp/) v0.3.7: Fix ACK window/UNA fields, generic Transport trait with RPITIT, resilience tests, criterion benchmarks v0.3.4: Engine refactoring, lock-free buffer pools, documentation v0.3.3: Performance optimizations, sub-millisecond latency v0.3.1: Full async support, comprehensive configuration v0.2.x: Performance improvements and bug fixes v0.1.x: Initial implementation

核心能力

• 混合架构：兼顾 B+ 树读速与 LSM 树写吞吐
• MVCC 并发：非阻塞的并发读写
• 闪存优化：面向 SSD/NVMe 的 log-structured 设计
• 大值分离：独立 Blob 存储，减少写放大
• ACID 事务：完整的事务支持

性能数据

注：以上为与 RocksDB 对比的中位数倍数。

适用场景

• 需要高并发读写的嵌入式服务（尤其是 mixed/read-heavy 负载）
• 写入吞吐敏感的本地存储层（中小 value 场景优势更明显）
• 混合读写 + 扫描的业务
• 需要本地事务和 MVCC 的 Rust 应用

地址

• 源码：https://github.com/abbycin/mace
• Benchmark 脚本：https://github.com/abbycin/kv_bench（scale 分支）

mace 还在非常早期的阶段，目前还在努力提升稳定性以及对特定workload进行优化...

0.0.29 版更新

Rudis 是一个采用 Rust 语言编写得高性能键值存储系统，旨在利用 Rust 语言的优势来重新复现 Rudis 的核心功能，以满足用户对高性能、可靠性和安全性的需求，同时保证与 Rudis API 的兼容。

跨平台，兼容 windows、linux 系统架构。 兼容 字符串、集合、哈希、列表、有序集合数据结构。 提供 rdb 与 aof 机制以支持数据备份和恢复。 拥有卓越的处理速度和即时响应能力。 兼容 Rudis 的命令和协议规范。

欢迎在 GitHub 上关注我们的项目发展轨迹：

👉 https://github.com/lunar-landing/rudis

更新日志：

• 新增 List 数据结构 Blpop、Brpop 命名。
• 新增 Hash 数据结构 HSCAN 命令，支持 MATCH 和 COUNT 参数。
• 新增 String 数据结构 SETEX、PSETEX、SETNX、SETBIT、GETBIT、BITCOUNT、BITOP 命令。
• 新增 Set 数据结构 SRANDMEMBER、SDIFFSTORE、SINTERSTORE、SMOVE 命令。
• 新增 HyperLogLog 数据结构及 PFADD、PFCOUNT、PFMERGE 命令。
• 重构 SortedSet 底层实现，采用 HashMap + SkipList 架构提升性能，并支持 bincode 序列化。
• 修复 SETEX/PSETEX 过期记录清理逻辑以及系统时间倒退导致的 RDB 调度 Panic 问题。

这几年接私活、做外包、做独立项目，有一个问题一直困扰我：

我们其实不知道一个项目「合理的价格」是多少。

不是技术难度不知道，而是——
你不知道别人真实成交是多少，只能靠猜、靠平台最低价、靠「听说」。

需求方会说：

「别人比你便宜一半。」

开发者只能纠结：

「我是报高了，还是别人报低了？」

时间久了，就变成大家都在往下试探，
内卷不是某个人的选择，而是信息不透明的结果。

我已经做了什么

我先从自己开始。

我把自己这几年做过的一些真实项目整理出来，包括：

• 项目类型
• 实际成交价格
• 大概工期
• 是否反复改需求
• 是否包含售后

做成了一个 独立开发者行情板。

目前一共 23 个案例：

• 大部分是我自己的真实成交
• 少部分是朋友的
• 也有几个是匿名提交的

我不回避这个事实：
数据现在还很少，而且并不「漂亮」。

但它至少是真实的。

为什么我需要更多人，而不是「更多数据」

我一个人的案例，其实没什么意义。

但如果有：

• 50 个
• 100 个
• 200 个

来自不同背景、不同技术栈、不同城市的真实案例，
至少可以做到一件事：

让后来的人，在报价时有一个不被平台最低价绑架的参考。

你不需要证明你多厉害，
也不需要报一个「体面」的价格，
真实比好看重要。

关于匿名和安全

我知道大家最担心什么，所以我一开始就做了两件事：

• 提供 匿名提交
• 不要求任何可追溯身份信息

目前有两个入口：

飞书表单 行情板网站

不署名、不展示来源、不做商业售卖。
你可以只写你愿意写的字段。

说一句更远一点的想法（不画饼）

行情板不是终点。

我真正想做的，是一个 不竞价、不抽佣、不负责售后 的撮合平台，
只做一件事：

把预算真实的需求方，和愿意按合理价格做事的开发者，匹配到一起。

行情板只是前战，是定价共识的基础。
如果连「合理价格区间」都没有，
任何撮合都会退化成比谁便宜。

我不确定这条路能走多远，
但至少想先试一次。

最后

如果你愿意贡献一个案例：

• 成功的
• 失败的
• 觉得自己报低了的
• 或者被压价压得很难受的

都可以。

如果你不想提交，也没关系，
至少希望这个东西能让你下次报价时，心里多一点底气。

• 算力层聚合：广泛接入全球闲散 GPU 算力资源，通过标准化调度技术实现算力的统一管理与高效利用；

• 服务层赋能：在聚合算力之上深度部署 MaaS 模型服务，客户无需投入高昂成本搭建算力与模型架构，只需通过简洁的大模型接口，即可按需调用 AI 能力，快速赋能业务创新。

算纽（GPUNexus）打通算力资源与模型应用的壁垒，让 AI 服务更便捷、更普惠。

2. 产品形态

2.1. 算力资产分享

算纽算力资产分享产品，核心打破算力孤岛，依托智能调度技术，实现各类计算资源一键接入、整合与统一调度，激活分散算力价值。

产品支持全场景接入，覆盖算力中心、企业服务器等专业设备及个人电脑、手机等终端，实现“云-边-端”全域覆盖。无论闲置算力拥有方（企业/机构/个人）还是算力需求方，均可通过平台精准匹配、高效流转。

无需复杂配置即可快速上线，智能调度实现供需实时匹配，既提升算力利用率，又帮助需求方降本、分享方变现，构建互利共赢的算力生态。

2.2. MAAS服务

算纽 MaaS服务，一站式整合30 余款主流开源大模型矩阵，囊括 DeepSeek、Qwen、GLM、Kimi、MiniMax 等明星模型，深度覆盖编程开发、学术研究与论文创作、数学推理、视觉处理与多模态交互、对话与长文本处理五大核心场景。

2.3. 开发者套餐

算纽开发者套餐，专为学生、独立开发者及中小团队量身定制，以超高性价比解锁顶级大模型编程能力，让每一份开发需求都能高效落地。

套餐核心优势直击开发痛点：成本颠覆性降低，计费低至传统tokens计费的一折，大幅压缩开发成本；模型自由切换，无需冗余购买多平台会员，一键直达GLM-4.7、MiniMax-M2.1、Kimi-K2三大顶级编程模型，最新最强的模型能力随心选；高效创作不等待，生成速度媲美同类高级套餐，助力快速完成代码编写、调试、优化等核心工作。

更有7天免费体验限时开启！零成本即可抢先体验顶级模型的强悍编程能力，轻松开启高效开发新体验。

​

• 官方网址：https://gpunexus.com/
• 咨询电话：010-53650986
• 联系邮箱：data@chengfangtech.com

一个终端看板应用，灵感来自 Helix 编辑器的键位设计。

预览

特性

• 📁 基于文件存储 - 使用 Markdown 文件和 TOML 配置，易于版本控制
• 🎯 多项目支持 - 支持全局项目和本地项目（.kanban/）
• ⌨️ Helix 风格键位 - 符合直觉的键盘快捷键
• 🪟 窗口管理 - 支持垂直/水平分屏，同时查看多个项目，自动保存和恢复工作区布局
• 🎨 现代 TUI - 基于 ratatui 的美观终端界面
• 📝 Markdown 支持 - 任务使用 Markdown 格式，支持外部编辑器
• 🔍 任务预览 - 内置预览和外部预览工具支持
• ⚙️ 自动配置 - 首次运行自动检测编辑器和预览器

安装

从 crates.io 安装

cargo install helix-kanban

从源码构建

git clone https://github.com/menzil/helix-kanban.git
cd helix-kanban
cargo build --release

快速开始

首次运行会显示欢迎对话框，自动检测系统编辑器和 Markdown 预览器：

hxk

输入法切换（macOS）

为了更好的输入体验，在正常模式下自动切换到英文输入法，在对话框模式（如创建/编辑任务）时保持用户的输入法。

推荐安装 im-select 工具：

# 使用 Homebrew 安装
brew install im-select

# 或者使用 curl 安装
curl -Ls https://raw.githubusercontent.com/daipeihust/im-select/master/install_mac.sh | sh

注意：如果不安装 im-select，程序仍可正常运行，只是不会自动切换输入法。

配置管理

查看当前配置：

hxk config show

设置编辑器：

hxk config editor nvim
hxk config editor "code --wait"

设置 Markdown 预览器：

hxk config viewer glow
hxk config viewer "open -a Marked 2"

键位绑定

基础导航

任务操作

项目管理

窗口管理

命令模式

按 : 进入命令模式，支持的命令：

• :q / :quit - 退出应用
• :open / :po - 打开项目
• :new / :pn - 创建新项目（全局）
• :new-local / :pnl - 创建新项目（本地）
• :add / :tn - 创建新任务
• :edit / :te - 编辑任务
• :view / :tv - 预览任务
• :reload / :r / :refresh - 重新加载当前项目
• :reload-all / :ra / :refresh-all - 重新加载所有项目
• :vsplit / :sv - 垂直分屏
• :hsplit / :sh - 水平分屏
• :help / :h - 显示帮助

数据存储

全局项目

全局项目存储在 ~/.kanban/projects/ 目录下。

本地项目

在任何目录下按 n 创建本地项目，会在当前目录的 .kanban/ 下存储：

your-project/
├── .kanban/
│   └── kanban-project/
│       ├── .kanban.toml
│       ├── todo/
│       ├── doing/
│       └── done/
└── ... (你的其他文件)

项目结构

project-name/
├── .kanban.toml          # 项目配置
├── todo/                 # Todo 任务
│   ├── 001.md
│   └── 002.md
├── doing/                # 进行中任务
│   └── 003.md
└── done/                 # 完成的任务
    └── 004.md

任务文件格式

任务以 Markdown 格式存储：

# 任务标题

created: 2025-12-10T10:30:00+08:00
priority: high

任务的详细描述内容...

## 子任务

- [ ] 子任务 1
- [x] 子任务 2

配置文件

应用配置存储在 ~/.kanban/config.toml：

editor = "nvim"
markdown_viewer = "glow"

# 隐藏的全局项目列表（软删除）
hidden_projects = ["old-project", "archived-project"]

工作区状态保存

应用会自动保存窗口布局和工作状态，下次启动时恢复：

保存内容：

• 分屏结构（垂直/水平分割）
• 每个窗格打开的项目
• 当前选中的列和任务
• 聚焦的窗格

保存位置：

• 全局工作区：~/.kanban/workspace.toml - 在任何目录启动时使用
• 本地工作区：.kanban/workspace.toml - 在项目目录下启动时优先使用

使用场景：

• 经常需要同时查看多个项目？设置好分屏布局后，下次启动自动恢复
• 在不同项目目录工作？每个目录都有自己独立的工作区布局
• 想要重置布局？使用命令 :reset-layout 恢复默认单窗格

示例工作区配置 (workspace.toml)：

# 自动生成，通常无需手动编辑
focused_pane = 2
next_pane_id = 4

[[panes]]
id = 0
type = "horizontal_split"
left = 1
right = 2

[[panes]]
id = 1
type = "leaf"
project = "work-project"
selected_column = 1
selected_task_index = 0

[[panes]]
id = 2
type = "leaf"
project = "personal-project"
selected_column = 0
selected_task_index = 2

开发

# 运行开发版本
cargo run

# 运行测试
cargo test

# 构建 release 版本
cargo build --release

致谢

• 键位设计灵感来自 Helix Editor
• UI 框架使用 ratatui

许可证

MIT OR Apache-2.0

今天的核心主题是：如何利用 Rust 过程宏的强大能力，将这些繁琐的持久化逻辑自动化，让开发者只需声明字段，即可获得健壮的乐观锁支持。

宏架构：分治与协作

实现一个完整的、自动化的乐观锁流程，需要宏在两个不同的代码层面进行注入和协作：

1. 数据变更层 (ActiveModelBehavior)：负责在数据写入数据库前，自动管理版本号 (version) 和时间戳 (updated_at) 的递增/更新。
2. 持久化操作层 (Repository::save)：负责实现核心的原子更新逻辑，即 CAS 检查。

Part 1: ActiveModel 的预处理钩子 (before_save)

这是我们实现乐观锁的第一步：确保在更新操作中，版本号能够正确地 自增。

我们通过宏注入或修改 sea-orm::ActiveModelBehavior Trait 的 before_save 钩子。

宏注入逻辑概览：

// 宏片段：insert_active_model_behavior_impl 的核心逻辑
if need_version {
    let version_stmt = quote! {
        if insert {
            // 插入 (insert=true) 时，版本号初始化为 1
            self.version = Set(1);
        } else if self.is_changed() {
            // 更新 (insert=false) 且模型有业务字段变化时，版本号自增
            let current_version = match self.version {
                Set(v) => *v,
                _ => 0,
            };
            self.version = Set(current_version + 1);
        }
    };
}
// updated_at 逻辑类似：非插入且 is_changed 时设置为当前时间

关键成果： 当我们在 Repository 中执行更新操作时，ActiveModel 已经通过 before_save 确保了两个重要事实：

1. 它携带着我们从数据库中读出的 旧版本号。
2. 它将尝试写入的 version 值，是 旧版本号 + 1。

Part 2: Repository 的原子 CAS 更新 (save 方法)

这是乐观锁实现的核心战场，由 fn create_tenant_save_impl 宏片段生成。其逻辑必须严格遵循 三步走 策略，以处理成功、冲突和首次插入三种情况。

Step 1: 原子 UPDATE (Compare-and-Swap)

我们使用 sea-orm 的 update_many 配合 filter 条件，来实现原子性检查。

我们从聚合根 (entity) 中取出 旧版本（即 current_version），并将其作为 WHERE 子句的一部分。

// 宏片段：create_tenant_save_impl 的核心 CAS 逻辑

// 从聚合获取当前版本（即期望的旧版本）
let current_version = entity_model.#optimistic_lock_field_ident();

// 1) 原子 UPDATE（带 version CAS）
let res = models::Entity::update_many()
    #id_filters // 主键和 TenantId 过滤
    // ⬇️ 核心：只有当数据库中的版本号等于旧版本号时，才允许更新 ⬇️
    .filter(models::Column::#optimistic_lock_col_ident.eq(current_version)) 
    .set(update_model.clone())
    .exec(&conn)
    .await?;

if res.rows_affected > 0 {
    // 成功！说明版本匹配，且更新成功写入
    // ... 事件处理并返回 Ok(())
    return Ok(());
}

如果 rows_affected > 0，任务圆满完成。如果 rows_affected == 0，则进入下一步判断。

Step 2 & 3: 冲突检测与首次插入

如果 CAS 更新失败（rows_affected == 0），我们需要区分是 版本冲突（记录存在但版本号不匹配）还是 首次插入（记录根本不存在）。

// 2) UPDATE 未命中，检查记录是否存在
if models::Entity::find()
    #id_filters // 仅按主键和 TenantId 查找
    .one(&conn)
    .await?
    .is_some()
{
    // 记录存在，但 Step 1 未命中 -> 乐观锁冲突！
    return Err(#crate_root::domain::RepositoryError::optimistic_lock_error(
        "Optimistic lock conflict: Version mismatch".to_string(),
    ));
}

// 3) 记录不存在，执行首次插入
let insert_model: models::Model = entity_model.clone().try_into()?;
let mut active_model = insert_model.into_active_model();
active_model.insert(&conn).await?;
// ... 事件处理并返回 Ok(())

Talk is cheap, show me the code

before_save

fn insert_active_model_behavior_impl(input: &mut ItemMod, model_config: &ModelConfig) {
  let Some((_, items)) = &mut input.content else {
      return;
  };

  let mut has_active_model_behavior = false;
  for item in items.iter_mut() {
      if let syn::Item::Impl(item_impl) = item
          && let Some((_, path, _)) = &item_impl.trait_
          && path.segments.last().unwrap().ident == "ActiveModelBehavior"
      {
          has_active_model_behavior = true;
          break;
      }
  }

  if !has_active_model_behavior {
      let active_model_behavior_impl = quote! {
          #[async_trait]
          impl ActiveModelBehavior for ActiveModel {
              async fn before_save<C>(mut self, db: &C, insert: bool) -> Result<Self, DbErr>
              where
                  C: ConnectionTrait,
              {
                  Ok(self)
              }
          }
      };
      items.push(parse_quote!(#active_model_behavior_impl));
  }

  for item in items.iter_mut() {
      if let syn::Item::Impl(item_impl) = item
          && let Some((_, path, _)) = &item_impl.trait_
          && path.segments.last().unwrap().ident == "ActiveModelBehavior"
      {
          let mut has_before_save = false;
          for item in item_impl.items.iter_mut() {
              if let syn::ImplItem::Fn(method) = item
                  && method.sig.ident == "before_save"
              {
                  has_before_save = true;
                  break;
              }
          }

          if !has_before_save {
              let before_save_method = quote! {
                  async fn before_save<C>(mut self, db: &C, insert: bool) -> Result<Self, DbErr>
                  where
                      C: ConnectionTrait,
                  {
                      Ok(self)
                  }
              };
              item_impl.items.push(parse_quote!(#before_save_method));
          }

          let need_created_at = model_config
              .fields
              .iter()
              .any(|f| f.ident.as_ref().unwrap() == "created_at");
          let need_updated_at = model_config
              .fields
              .iter()
              .any(|f| f.ident.as_ref().unwrap() == "updated_at");

          let need_version = model_config
              .fields
              .iter()
              .any(|f| f.ident.as_ref().unwrap() == "version");

          if !(need_created_at || need_updated_at || need_version) {
              return;
          }

          for item in item_impl.items.iter_mut() {
              if let syn::ImplItem::Fn(method) = item
                  && method.sig.ident == "before_save"
              {
                  let mut stmts = Vec::new();
                  stmts.push(quote! {
                      let now = chrono::Utc::now();
                  });

                  if need_created_at {
                      let created_at_stmt = quote! {
                          if insert {
                              self.created_at = Set(now);
                          }
                      };
                      stmts.push(created_at_stmt);
                  }
                  if need_updated_at {
                      let updated_at_stmt = quote! {
                          if insert {
                              self.updated_at = Set(now);
                          } else if self.is_changed() {
                              self.updated_at = Set(now);
                          }
                      };
                      stmts.push(updated_at_stmt);
                  }

                  if need_version {
                      let version_stmt = quote! {
                          if insert {
                              self.version = Set(1);
                          } else if self.is_changed() {
                              let current_version = match self.version {
                              Set(v) => *v,
                              _ => 0,
                          };
                              self.version = Set(current_version + 1);
                          }
                      };
                      stmts.push(version_stmt);
                  }

                  let stmts = parse_quote!({#(#stmts)*});

                  // 插入到方法体的开头
                  method.block.stmts.insert(0, stmts);
              }
          }
      }
  }
}

宏生成的代码示例

 impl ActiveModelBehavior for ActiveModel {
        #[allow(
            elided_named_lifetimes,
            clippy::async_yields_async,
            clippy::diverging_sub_expression,
            clippy::let_unit_value,
            clippy::needless_arbitrary_self_type,
            clippy::no_effect_underscore_binding,
            clippy::shadow_same,
            clippy::type_complexity,
            clippy::type_repetition_in_bounds,
            clippy::used_underscore_binding
        )]
        fn before_save<'life0, 'async_trait, C>(
            self,
            db: &'life0 C,
            insert: bool,
        ) -> ::core::pin::Pin<
            Box<
                dyn ::core::future::Future<Output = Result<Self, DbErr>>
                    + ::core::marker::Send
                    + 'async_trait,
            >,
        >
        where
            C: ConnectionTrait,
            C: 'async_trait,
            'life0: 'async_trait,
            Self: 'async_trait,
        {
            Box::pin(async move {
                if let ::core::option::Option::Some(__ret) =
                    ::core::option::Option::None::<Result<Self, DbErr>>
                {
                    #[allow(unreachable_code)]
                    return __ret;
                }
                let mut __self = self;
                let insert = insert;
                let __ret: Result<Self, DbErr> = {
                    {
                        let now = chrono::Utc::now();
                        if insert {
                            __self.created_at = Set(now);
                        }
                        if insert {
                            __self.updated_at = Set(now);
                        } else if __self.is_changed() {
                            __self.updated_at = Set(now);
                        }
                    }
                    Ok(__self)
                };
                #[allow(unreachable_code)]
                __ret
            })
        }
    }

Repository::save

fn create_tenant_save_impl(
    crate_root: &Path,
    aggregate: &Path,
    args: &RepositoryStructArgs,
    id_filters: &TokenStream,
) -> TokenStream {
    // 若指定了乐观锁字段，准备字段名/Column ident
    let optimistic_lock_field = args.optimistic_lock_field.as_ref().map(|lit| {
        let optimistic_lock_field_name = lit.value();
        let optimstic_lock_field_ident = new_id(&optimistic_lock_field_name); // 用于 ActiveModel/Model 字段访问
        let optimistic_lock_col_ident = new_id(&to_pascal_case(&optimistic_lock_field_name)); // 用于 models::Column::Xxx
        (
            optimistic_lock_field_name,
            optimstic_lock_field_ident,
            optimistic_lock_col_ident,
        )
    });

    // 根据是否指定乐观锁字段，生成 save 的实现
    if let Some((
        optimistic_lock_field_name,
        optimistic_lock_field_ident,
        optimistic_lock_col_ident,
    )) = optimistic_lock_field
    {
        if optimistic_lock_field_name == "version" {
            quote! {
                async fn save(
                    &self,
                    txn: &mut TC,
                    entity: &mut #crate_root::domain::EventSourcedEntity<#aggregate>,
                ) -> Result<(), #crate_root::domain::RepositoryError> {
                    use #crate_root::domain::SeaOrmModelUpdater;
                    use sea_orm::{ActiveModelTrait, ColumnTrait, EntityTrait, IntoActiveModel, QueryFilter};
                    use sea_orm::ActiveValue::Set;

                    let conn = txn.get_connection();
                    let entity_model: &#aggregate = entity;

                    let id = entity_model.id();
                    let tenant_id = entity_model.tenant_id();

                    // 从聚合获取当前版本与期望旧版本
                    let current_version = entity_model.#optimistic_lock_field_ident();

                    // 构造用于原子更新的 ActiveModel（只写回必要列）
                    let mut update_model = models::Model::from(entity_model.clone()).into_active_model();

                    // 1) 原子 UPDATE（带 version CAS）
                    let res = models::Entity::update_many()
                        #id_filters
                        .filter(models::Column::TenantId.eq(*tenant_id))
                        .filter(models::Column::#optimistic_lock_col_ident.eq(current_version))
                        .set(update_model.clone())
                        .exec(&conn)
                        .await?;

                    if res.rows_affected > 0 {
                        entity.move_event_to_context(txn);
                        return Ok(());
                    }

                    // 2) UPDATE 未命中，检查记录是否存在（按主键 + tenant）
                    if models::Entity::find()
                        #id_filters
                        .filter(models::Column::TenantId.eq(*tenant_id))
                        .one(&conn)
                        .await?
                        .is_some()
                    {
                        return Err(#crate_root::domain::RepositoryError::optimistic_lock_error(
                            "Optimistic lock conflict: Version mismatch".to_string(),
                        ));
                    }

                    // 3) 记录不存在，插入数据
                    let insert_model: models::Model = entity_model.clone().try_into()?;
                    let mut active_model = insert_model.into_active_model();
                    active_model.insert(&conn).await?;
                    entity.move_event_to_context(txn);
                    Ok(())
                }
            }
        } else {
            // treat as timestamp update_at
            quote! {
                async fn save(
                    &self,
                    txn: &mut TC,
                    entity: &mut #crate_root::domain::EventSourcedEntity<#aggregate>,
                ) -> Result<(), #crate_root::domain::RepositoryError> {
                    use #crate_root::domain::SeaOrmModelUpdater;
                    use sea_orm::{ActiveModelTrait, ColumnTrait, EntityTrait, IntoActiveModel, QueryFilter};
                    use sea_orm::ActiveValue::Set;
                    use chrono::Utc;

                    let conn = txn.get_connection();
                    let entity_model: &#aggregate = entity;

                    let id = entity_model.id();
                    let tenant_id = entity_model.tenant_id();

                    // 读取实体携带的旧时间戳与准备新的时间戳
                    let current_ts = entity_model.#optimistic_lock_field_ident();

                    // 构造用于原子更新的 ActiveModel
                    let mut update_model = models::Model::from(entity_model.clone()).into_active_model();

                    // 1) 原子 UPDATE（带 updated_at CAS）
                    let res = models::Entity::update_many()
                        #id_filters
                        .filter(models::Column::TenantId.eq(*tenant_id))
                        .filter(models::Column::#optimistic_lock_col_ident.eq(current_ts))
                        .set(update_model.clone())
                        .exec(&conn)
                        .await?;

                    if res.rows_affected > 0 {
                        entity.move_event_to_context(txn);
                        return Ok(());
                    }

                    // 2) UPDATE 未命中，检查记录是否存在
                    if models::Entity::find()
                        #id_filters
                        .filter(models::Column::TenantId.eq(*tenant_id))
                        .one(&conn)
                        .await?
                        .is_some()
                    {
                        return Err(#crate_root::domain::RepositoryError::optimistic_lock_error(
                            "Optimistic lock conflict".to_string(),
                        ));
                    }

                    // 3) 记录不存在，直接插入数据
                    let insert_model: models::Model = entity_model.clone().try_into()?;
                    let mut active_model = insert_model.into_active_model();

                    active_model.insert(&conn).await?;
                    entity.move_event_to_context(txn);
                    Ok(())
                }
            }
        }
    } else {
        // no optimistic lock field -> simple update/insert behavior (原始实现)
        quote! {
            async fn save(
                &self,
                txn: &mut TC,
                entity: &mut #crate_root::domain::EventSourcedEntity<#aggregate>,
            ) -> Result<(), #crate_root::domain::RepositoryError> {
                use #crate_root::domain::SeaOrmModelUpdater;
                use sea_orm::{ActiveModelTrait, ColumnTrait, EntityTrait, IntoActiveModel, QueryFilter};

                let conn = txn.get_connection();

                let entity_model: &#aggregate = entity;

                let id = entity_model.id();
                let tenant_id = entity_model.tenant_id();

                if let Some(mut model) = models::Entity::find()
                    #id_filters
                    .filter(models::Column::TenantId.eq(*tenant_id))
                    .one(&conn)
                    .await?
                {
                    if &model.tenant_id != tenant_id {
                        return Err(#crate_root::domain::RepositoryError::mapping_error(
                            format!(
                                "Tenant ID mismatch: expected {}, found {}, id: {}",
                                tenant_id, model.tenant_id, id
                            ),
                        ));
                    }

                    // 更新逻辑
                    model.update_from_aggregate_root(entity_model).await?;

                    let active_model = model.into_active_model();
                    active_model.update(&conn).await?;
                } else {
                    // 创建新记录
                    let model: models::Model = entity_model.clone().try_into()?;
                    let active_model = model.into_active_model();
                    active_model.insert(&conn).await?;
                }

                entity.move_event_to_context(txn);
                Ok(())
            }
        }
    }
}

宏生成的代码示例

  async fn save(
        &self,
        txn: &mut TC,
        entity: &mut core_common::domain::EventSourcedEntity<TenantUser>,
    ) -> Result<(), core_common::domain::RepositoryError> {
        use core_common::domain::SeaOrmModelUpdater;
        use sea_orm::{
            ActiveModelTrait, ColumnTrait, EntityTrait, IntoActiveModel, QueryFilter,
        };
        use sea_orm::ActiveValue::Set;
        use chrono::Utc;
        let conn = txn.get_connection();
        let entity_model: &TenantUser = entity;
        let id = entity_model.id();
        let current_ts = entity_model.update_at();
        let mut update_model = models::Model::from(entity_model.clone())
            .into_active_model();
        let res = models::Entity::update_many()
            .filter(models::Column::Id.eq((id.tenant_id(), id.user_id())))
            .filter(models::Column::UpdateAt.eq(current_ts))
            .set(update_model.clone())
            .exec(&conn)
            .await?;
        if res.rows_affected > 0 {
            entity.move_event_to_context(txn);
            return Ok(());
        }
        if models::Entity::find()
            .filter(models::Column::Id.eq((id.tenant_id(), id.user_id())))
            .one(&conn)
            .await?
            .is_some()
        {
            return Err(
                core_common::domain::RepositoryError::optimistic_lock_error(
                    "Optimistic lock conflict".to_string(),
                ),
            );
        }
        let insert_model: models::Model = entity_model.clone().try_into()?;
        let mut active_model = insert_model.into_active_model();
        active_model.insert(&conn).await?;
        entity.move_event_to_context(txn);
        Ok(())
    }

兼容性处理

宏的另一个优势是其灵活性。它能根据字段名称自动适配不同的乐观锁策略：

• 如果检测到字段为 "version"，则执行版本号的 CAS 逻辑。
• 如果检测到其他时间戳字段如 "updated_at"，则执行基于时间戳的 CAS 逻辑。

结论

通过将 before_save 中的版本递增逻辑，与 Repository::save 中的原子 CAS 检查完美结合，我们使用 Rust 过程宏实现了一个 高内聚、低耦合 的乐观锁基础设施。

开发者现在可以专注于业务逻辑，而将并发控制的复杂性和样板代码完全交给宏来处理。这不仅极大地提高了开发效率，同时也确保了底层持久化操作的健壮性和一致性。

一、乐观锁：不是不锁，而是“巧”锁

数据库的并发控制主要分为悲观锁和乐观锁。

• 悲观锁（Pessimistic Locking）： 假设冲突一定会发生。在读取数据时就对数据行进行锁定，直到事务完成。
• 乐观锁（Optimistic Locking）： 假设冲突很少发生。在整个事务过程中不锁定资源，而是通过检查数据是否被修改来确认。

乐观锁的核心思想是：通过一次原子性的操作来检查并修改数据，而不是依赖两次独立的数据库操作。

二、没有锁的陷阱：丢失更新的竞态条件

让我们以一个 version: i32 字段为例，来看看缺乏原子性操作会导致什么问题。

场景：多人同时更新同一条记录

1. 查询（事务 A/B）： 事务 A 和事务 B 都读取了 ID=1 的记录，其 version 都为 1。
2. 更新（事务 B 提交）： 事务 B 完成修改，执行 无版本检查 的 UPDATE 语句，数据库中的 version 变为 2。
3. 更新（事务 A 提交）： 事务 A 完成修改，也执行 无版本检查 的 UPDATE 语句。

结果： 事务 B 的业务变更被事务 A 的修改覆盖，导致 丢失更新（Lost Update） 的竞态条件。

乐观锁的解决之道：单次原子操作

要解决这个问题，必须让 “检查旧版本” 和 “设置新值” 成为一个原子操作，即在 UPDATE 语句中加入版本过滤条件：

UPDATE records
SET title = '新标题', version = version + 1
WHERE id = 1 AND version = 1; -- 关键：只有旧版本为 1 时才允许更新

在 SeaORM 中，我们使用 update_many() 配合 filter() 来构造这个原子操作，并通过检查 rows_affected 来判断操作是否成功。

三、Upsert 流程的抉择：先 Update 再 Insert 的优势

实现 Upsert 功能主要有两种策略：“先 Update 再 Insert” 和 “先 Insert 再 Update”。在涉及乐观锁的业务中，“先 Update 再 Insert” 模式是更优的选择。

1. 模式一：先 Update 再 Insert（推荐）

这种模式总是优先处理最常见的情况：更新现有记录。

优势分析：

• 天然支持乐观锁： 乐观锁检查（WHERE version = ?）直接集成在 UPDATE 语句中，利用了数据库的原子性，保证了在单次操作中完成检查和修改。
• 高效处理更新： 在高并发的更新场景中，大部分操作都是更新。这种模式只需执行一次成功的 UPDATE 就能完成任务，避免了不必要的 INSERT 尝试。

2. 模式二：先 Insert 再 Update

流程： 尝试 INSERT $\to$ 如果失败（主键冲突），执行 UPDATE。

劣势分析：

• 乐观锁实现复杂： 如果 INSERT 失败，转到 UPDATE 时，必须确保 UPDATE 操作是带有乐观锁检查的，这增加了流程的复杂性。
• 高更新场景效率低： 如果大部分操作是更新，这种模式会强制执行一次注定会失败的 INSERT 操作（抛出主键冲突错误），然后再执行一次 UPDATE，浪费了数据库资源。

总结：选择 “先 Update 再 Insert” 的理由

在处理带有乐观锁的聚合根持久化时，“先 Update 再 Insert” 模式是首选方案。它能够利用 UPDATE 的原子性高效地处理最常见的更新操作，并天然地将乐观锁检查与数据库写操作绑定。

四、SeaORM 中的 Upsert 流程：UPDATE $\to$ FIND $\to$ INSERT

基于 “先 Update 再 Insert” 的策略，我们构建一个清晰的 "原子 UPDATE + FIND + INSERT" 三步流程，以可靠地处理成功更新、并发冲突和成功插入三种情况。

核心实现代码

// 假设 entity.version 是更新后的新版本，expected_old_version = entity.version - 1
async fn save<T: TransactionContext>(
    &self,
    callback: &mut EventSourcedEntity<Callback>,
    txn: &mut T,
) -> Result<(), RepositoryError> {
    let conn = txn.get_connection();
    let entity: &Callback = callback;
    let id = entity.channel.0.clone(); 
    let expected_old_version = entity.version - 1; 

    // 准备 ActiveModel，设置新的 version
    let mut active_model_for_update: ActiveModel = entity.clone().into_active_model();
    active_model_for_update.version = Set(entity.version); 

    // ----------------------------------------------------
    // 第一步：尝试原子 UPDATE（带乐观锁）
    // ----------------------------------------------------
    let res = callback_model::Entity::update_many()
        .set(active_model_for_update)
        .filter(callback_model::Column::Channel.eq(id.clone())) 
        .filter(callback_model::Column::Version.eq(expected_old_version)) // 乐观锁检查
        .exec(conn)
        .await?;

    if res.rows_affected > 0 {
        // 更新成功：影响行数 > 0，说明乐观锁条件满足。
        callback.move_event_to_context(txn);
        return Ok(());
    }

    // ----------------------------------------------------
    // 第二步：UPDATE 失败。使用 FIND 检查记录是否存在（判断是否为并发冲突）
    // ----------------------------------------------------
    if callback_model::Entity::find_by_id(id.clone())
        .one(conn)
        .await?
        .is_some()
    {
        // 记录存在。UPDATE 失败且记录存在，必然是版本不匹配，即并发冲突。
        return Err(RepositoryError::optimistic_lock_error(
            "Optimistic lock conflict: Record exists, but old version did not match."
        ));
    }

    // ----------------------------------------------------
    // 第三步：记录不存在，尝试 INSERT
    // ----------------------------------------------------
    let active_model_for_insert: ActiveModel = entity.clone().into_active_model();
    
    active_model_for_insert.insert(conn).await
        .map_err(|e| {
             // 如果 INSERT 失败，则视为并发冲突（在 FIND 之后被其他事务插入）。
             match e {
                 DbErr::RecordNotInserted | DbErr::Custom(_) => RepositoryError::optimistic_lock_error(
                    "Concurrency conflict: Record inserted after non-existence check."
                 ),
                 _ => e.into(),
            }
        })?;

    callback.move_event_to_context(txn);
    Ok(())
}

结论：告别竞态，拥抱原子性

通过本文的分析和实践，我们可以得出以下关键结论：

1. 乐观锁是高并发的基石： 放弃“先查后改”的传统模式，将版本检查与数据修改集成到一次原子性的 UPDATE 操作中，是避免丢失更新等竞态条件的根本方法。
2. 选择正确的 Upsert 策略： “先 Update 再 Insert” 模式凭借其对乐观锁的天然支持和对更新操作的高效处理，成为处理聚合根持久化的首选。
3. 利用数据库的原子性： 无论是通过检查 rows_affected，还是依赖主键约束错误来区分更新失败的原因，都是在充分利用数据库底层机制来确保数据一致性。

在您的 Rust DDD/CQRS 架构中，将这种原子化逻辑封装进仓储（Repository）层的 save() 方法中，是确保数据完整性和系统高可用性的关键。