rpi 是 TypeScript 版 pi 的 Rust 移植。这类"重写"项目最常见的宣传口径是"Rust 更快"， 但快多少、快在哪、以及除了快还差在哪，通常没人讲清楚。

所以我把两个工具装在同一台机器上，用同一套协议跑了一遍，同时把两边的代码结构也摊开对比。

怎么测才公平

两个工具都是终端里的 coding agent，一个原生二进制，一个 Node 脚本，很容易测成"比谁启动快"这种没信息量的对比。所以口径先定死：

结果

环境：Windows 11 (26200) / x86_64、rustc 1.97.1 --release、Node v25.9.0、rpi 0.3.6、pi 0.87.1。3 轮预热后测 11 轮，取中位数。

原始数据（单位 ms）：

项目

rpi 是 Rust 原生开发，在开发中借鉴了大量 Pi 的思想，并做了一部分优化，有感兴趣的伙伴欢迎PR

• GitHub：https://github.com/bigfish1913/pi-rust
• 官网：https://rpi.laofu.online/
• 免 Rust 工具链安装：curl -fsSL https://raw.githubusercontent.com/bigfish1913/pi-rust/main/scripts/install.sh | sh

最近开源了 ulua，一个用纯 Rust 实现的 Luau 语言运行时。Luau 是 Roblox 基于 Lua 5.1 深度改造演进的脚本语言，具备渐进静态类型系统、寄存器虚拟机和编译优化管线。

在此之前，在 Rust 中嵌入使用 Luau 主要依赖基于 C++ 源码的 FFI 绑定（例如 mlua 的 luau feature）。使用 C++ 绑定需要依赖 C/C++ 交叉编译工具链，在需要静态编译、移植到嵌入式平台或编译为 WebAssembly 在浏览器内无缝运行时，配置流程会繁琐许多。

ulua 项目基于早期从 C++ 源码转译的 Rust 代码底座进行深度重写，包含从词法解析、AST 语法树、字节码编译、寄存器虚拟机、垃圾回收、静态类型推导到 A64/X64 本地机器码即时编译（CodeGen JIT）的完整处理管线，无需任何 C/C++ 编译依赖。

现状与开发重心

需要主动说明的是，项目目前处于活跃的重构与持续开发阶段：

当前阶段的主要工作，是集中消除 C/C++ 转译遗留下来的原始指针操作、精简 unsafe 代码块，并彻底移除各类警告忽略属性（#![allow(...)]）。我们正在逐步将大量 C 风格的数据流改写为惯用的 Rust 模式，以构建一个安全、可维护的现代化代码库。

目前代码尚未做细致的底层微架构性能调优。当前的执行效率主要得益于 Luau 本身简洁紧凑的寄存器虚拟机架构。我们计划在后续将所有 C 风格残余代码完全清洗、重构为纯正 idiomatic Rust 并且架构稳定后，再集中开展系统级的性能与 GC 优化。

性能基准实测数据

为了客观评估执行开销，测试套件采用纯 Rust 进程内微基准（消除外部子进程创建与终端 I/O 带来的干扰），在 Apple Silicon (Apple M2 Max, arm64) 平台上运行了 16 组经典计算密集用例（涵盖二叉树分配与 GC、40 万次协程切换、全排列、递归、曼德博分形、矩阵乘法、天体轨道模拟、谱范数逼近等），取各引擎多次运行的耗时中位数（单位：毫秒 ms）：

实测数据显示，在解释执行模式下，ulua 的几何平均耗时与官方 C++ Luau 基本一致（1.0 vs 1.02），且比官方 Lua 5.4 快约 17%；在开启 JIT 机器码生成（features = ["jit"]）后，计算密集型场景耗时降低约 48%（相对解释模式由 1.0 降至 0.52），水平与官方 C++ Luau JIT (0.57) 相当。

浏览器端 WebAssembly Playground

由于脱离了 C++ 编译链依赖，ulua 可以直接编译到 wasm32 目标。我们部署了一个纯静态的在线演练场：

https://webc-site.github.io/ulua

页面在浏览器端运行 WebAssembly 虚拟机，支持 Luau 代码的即时语法高亮、双向静态类型推导诊断以及虚拟机执行。

快速上手示例

在 Cargo.toml 中添加依赖：

[dependencies]
ulua = "0.1"

基础求值与字节码执行：

use ulua::{compile, eval, eval_bytecode};

fn main() -> Result<(), Box<dyn std::error::Error>> {
  // 直接求值
  eval("assert(1 + 1 == 2)")?;

  // 编译为二进制字节码
  let bytecode = compile("assert(10 * 20 == 200)")?;

  // 直接执行预编译字节码
  eval_bytecode(&bytecode)?;

  Ok(())
}

宿主环境交互与 JIT 控制：

use ulua::prelude::*;

fn main() -> Result<()> {
  let lua = Lua::new();

  // 默认使用纯解释执行
  lua.load("print('Hello from ulua interpreter')").exec()?;

  // 可通过 API 动态开关 JIT 机器码生成
  #[cfg(feature = "jit")]
  {
    lua.enable_jit(true)?;
    let sum: i64 = lua.load(r#"
      local total = 0
      for i = 1, 1000000 do
        total += i
      end
      return total
    "#).eval()?;
    assert_eq!(sum, 500000500000);
  }

  // 向 Luau 注册 Rust 函数
  let add = lua.create_function(|_, (a, b): (i64, i64)| Ok(a + b))?;
  lua.globals().set("add", add)?;

  let res: i64 = lua.load("return add(10, 20)").eval()?;
  assert_eq!(res, 30);

  Ok(())
}

交流与反馈

项目已在 GitHub 开源，发布于 crates.io。目前我们正在逐步清理各类历史遗留的 unsafe 块并补全测试用例。欢迎大家试用、提出 issue 反馈或提交 PR 共同改进。

为什么又做一个 Registry？

AI Agent 和高吞吐 CI 的工作方式与人工发版不太一样：一次任务可能反复经历“改代码—打包—部署—测试—再修改”，产生很多只存活几分钟或几小时的 snapshot、crate、wheel、容器层和工具链压缩包。把这些中间产物全部推到中心仓库，会引入网络延迟、限流，也会让长期仓库承担不必要的清理压力。

TeaQL Registry 更像是靠近 Runner 的 L1 Registry：

AI Agent / CI Runner
        │ 高频 publish / pull
        ▼
TeaQL Registry（本地或集群内）
        │ 只提升最终验证通过的版本
        ▼
Nexus / JFrog / 云端主仓库

目前支持什么？

项目目前支持 14 种制品格式：Docker Registry v2、Maven2、npm、PyPI、Cargo、Go Modules、NuGet、Swift Package Registry、Dart Pub、RubyGems、Composer、Conan 2、Hex，以及 Raw/Generic。

这里的重点是“软件开发过程中的组件”，而不是面向终端用户的软件商店。比如跨平台预编译工具链，我们建议直接用 Raw/Generic 保存按 OS、架构和版本组织的 .tar.gz / .zip；如果交付物本身是容器镜像，就使用 Docker/OCI；如果它属于某个语言生态，再选择对应的原生协议。

服务端支持 S3 兼容存储（RustFS、MinIO、AWS S3）、文件系统和内存模式，Blob 使用 SHA-256 内容寻址去重。管理侧提供多租户、RBAC、PAT、审计记录、保留策略和孤儿 Blob GC，并带有嵌入式 Web Console 与独立的 Ratatui TUI。

TUI 适合只有 SSH 的跳板机或构建节点，可以查询服务状态、仓库和组件，执行搜索、检查、清理、GC 与临时令牌生成。

Rust 在这里解决了什么？

Registry 的数据面有大量流式上传下载、校验、协议路由和并发请求。Rust 让我们可以在一个进程里完成协议适配、元数据服务和 Blob 流式传输，同时把资源生命周期和错误路径尽量前移到编译期处理。Axum/Tokio 负责 HTTP 与异步 I/O，TeaQL 负责领域模型、权限和可审计的数据变更，PostgreSQL 保存元数据；Web Console 被嵌入最终二进制，容器运行时镜像可以保持很小。

另一个实际收益是部署形态：服务端和 registry-tui 都可以构建成独立二进制，适合放进构建集群或受限网络环境。

TeaQL 在这个项目里做了什么？

Registry 很适合检验一个业务框架是否真的能处理复杂场景：它既有多租户和权限边界，又有大量列表查询，还要承受高频写入、版本竞争和跨实体关系读取。在 TeaQL Registry 中，TeaQL（下文简称 TQ）不是只负责把表映射成 Rust struct，而是把查询意图、租户上下文、变更审计、Mutation Policy 治理和数据加载状态一起带进业务代码。本文中的 Mutation Policy Approval 基于 TeaQL Rust Runtime 5.0.5。

这套 TeaQL 开发工具链已经支持 Java、Rust、TypeScript、Go、Swift、.NET 和 Python 七个运行时。同一份语义模型可以生成对应语言的类型化领域库与应用工作区，并通过模型感知 Assist 提供查询、分页、创建、修改、删除和表达式等开发指导。TeaQL Registry 选择 Rust 实现，但下面这些 TQ 编程模型并不只服务于 Rust。

1. 在 TQ 执行入口集中实施租户隔离

多租户隔离最怕依赖开发者记忆：如果要求每个 Service 都手写一次 filter_by_tenant(...)，迟早会有新接口漏掉。TeaQL Registry 把隔离放在 TQ 的统一执行入口 RequestPolicy 中。每一条查询在交给数据服务之前，都会经过 enforce_select；策略从可信 context 取得当前租户，并把条件与原查询合并：

impl RequestPolicy for TeaQLRegistryTenantRequestPolicy {
    fn enforce_select(
        &self,
        context: &UserContext,
        query: &mut SelectQuery,
    ) -> Result<(), RuntimeError> {
        // 集中维护模型中带 tenant 关系的实体集合
        if tenant_scoped_entities.contains(&query.entity.as_str()) {
            let tenant_id = context
                .get_resource::<TenantInfo>()
                .map(|tenant| tenant.tenant_id)
                .unwrap_or(1);
            let tenant_filter = Expr::eq("tenant_id", tenant_id);
            query.filter = Some(match query.filter.take() {
                Some(existing) => existing.and_expr(tenant_filter),
                None => tenant_filter,
            });
        }
        Ok(())
    }
}

HTTP 认证层只负责解析 Token、X-TeaQL-Tenant 或带租户限定的用户名，确认用户属于目标租户，然后创建请求级 TQ Runtime。set_tenant(...) 会同时写入 TenantInfo 并安装上述策略。后续业务查询只接收这个 context，不再传递 tenant_id，也不需要重复拼租户条件：

let repositories = RepositoryService::list(&tenant_context).await?;
let users = SecurityService::list_users(&tenant_context).await?;

项目的多租户集成测试会创建两个 context，然后用完全相同、没有租户参数的调用分别查询仓库、BlobStore 和用户，验证结果只来自各自租户。隔离因此是“默认发生”的基础设施能力，而不是散落在业务代码里的编码约定。

PAT 也绑定 tenant_id + user_id + username；即使原生包管理器把 Token 放在 Basic Auth 密码位置，服务端仍会重新校验这三者与当前租户是否一致。

2. 分页查询仍然保留类型和意图

管理端的服务日志查询是一个直接例子。过滤条件、稳定排序和分页都通过模型生成的 Q API 表达：

let rows = Q::service_logs_minimal()
    .select_self_fields()
    .order_by_id_desc()
    .offset(offset as u64, limit as u64)
    .comment("what: query registry service logs with bounded pagination")
    .purpose("why: render best-effort operational package history")
    .execute_for_list(context)
    .await?;

这段查询故意没有 filter_by_tenant(...)：租户条件会在 TQ 执行入口由 RequestPolicy 自动注入。order_by_id_desc() 给翻页提供确定顺序，offset/limit 限制单次物化规模；字段选择、关系选择和业务过滤方法则来自模型生成代码，字段改名或关系不存在会在编译阶段暴露。对于需要同时返回分页元数据的列表，TQ 还提供 execute_for_page(context, offset, limit)，返回 SmartList<T>，并由 Runtime 统一执行硬上限和查询策略。

这里的 comment 与 purpose 也不是装饰：它们把“查询了什么”和“为什么查询”带到执行阶段，缺失查询意图可以被策略拒绝，便于审计和诊断慢查询。

3. 修改数据走完整实体、校验和审计链

项目不会把外部 DTO 直接翻译成 UPDATE。修改组件前先通过同一个租户 context 加载完整实体，再调用模型生成的 update_xxx 方法，最后附加业务原因并保存。例如删除组件采用软删除：

let rows = Q::components()
    .select_self_fields()
    .with_id_is(component_id)
    .limit(1)
    .comment("what: query registry component metadata")
    .purpose("why: resolve package components and their assets")
    .execute_for_list(context)
    .await?;

if let Some(mut component) = rows.into_iter().next() {
    component.update_kind("deleted");
    component.update_name(format!("[DELETED_{}]", component.id()));
    component
        .audit_as("Deleting component")
        .save_with(context)
        .await?;
}

完整加载很重要：目标实体首先经过集中租户策略查询，TQ 的 checker 可以看到完整业务状态，实体原始版本也能参与乐观锁判断。audit_as(...) 让每次持久化都携带明确的业务原因；保存继续使用同一个请求 context，使查询、修改和审计处在同一条请求链路中。

4. 在事务之前完成 Mutation Policy Approval

audit_as(...) 解决的是“这次修改为什么发生”，Mutation Policy Approval 解决的是另一个问题：“允许这类修改的规则本身，是否经过了明确评审？”这不是订单、工单一类业务单据的人工审批流，而是对应用自定义写策略的版本化批准。

TeaQL 5.0.5 会在 Checker/Fix 和完整 Graph Planning 之后生成不可变的 MutationPlan。其中包含根实体、审计原因、Create/Update/Delete/Recover 操作、原始版本以及实际变更字段。Runtime 在开启数据库事务、执行第一条写入之前，把整份计划交给 MutationPolicy::review：

实体变更
   │
   ▼
Checker / Fix ──► 不可变 MutationPlan
                         │
                         ▼
                MutationPolicy::review
                    │              │
                  Deny           Allow
                    │              │
          事务开始前返回错误     精确查找 Policy Approval
                                   │
                                   ▼
                           事务写入 + 审计事件

应用策略可以对整张变更图做判断，而不必把规则散落在每个 Service 方法中。例如，Registry 可以要求每次写入都带审计原因，并限制一次保存携带的操作数量：

use teaql_runtime::{
    MutationDecision, MutationPlan, MutationPolicy, MutationPolicyIdentity, UserContext,
};

struct RegistryMutationPolicy;

impl MutationPolicy for RegistryMutationPolicy {
    fn identity(&self) -> MutationPolicyIdentity {
        MutationPolicyIdentity::new(
            "teaql-registry-write-policy",
            "1.0.0",
            "sha256:<reviewed-policy-fingerprint>",
        )
    }

    fn review(&self, _context: &UserContext, plan: &MutationPlan) -> MutationDecision {
        let missing_reason = plan
            .audit_reason
            .as_deref()
            .map(str::trim)
            .map(str::is_empty)
            .unwrap_or(true);
        if missing_reason {
            return MutationDecision::deny(
                "REGISTRY-AUDIT-REASON-REQUIRED",
                "registry mutations require an audit reason",
                ["audit_reason"],
            );
        }
        if plan.operations.len() > 128 {
            return MutationDecision::deny(
                "REGISTRY-MUTATION-TOO-LARGE",
                "one registry mutation may contain at most 128 operations",
                ["operations"],
            );
        }
        MutationDecision::allow()
    }
}

Policy 通过后，Runtime 再向可信的 MutationPolicyApprovalProvider 查询批准记录。批准必须同时匹配 Policy 的 id + version + fingerprint；只改版本号或代码指纹而沿用旧批准，都会被识别为未批准。Policy Registry、Approval Provider 和告警 Sink 都在服务端组装 UserContext 时安装，HTTP 或 TFP 请求不能从外部替换它们。

这里还有一个值得明确的兼容边界：没有安装客户 Policy 时，Runtime 允许原有写入并产生 MUTATION-POLICY-001；安装了客户 Policy 但没有精确批准时，会产生 MUTATION-POLICY-002。这两个状态目前是治理告警，不会冒充强制审批。真正的 Policy Deny 则会在事务开始前终止保存，保证没有部分数据落库。允许执行时，Policy 身份、Approval 状态、告警码和变更字段摘要会随 MutationGovernanceSnapshot 进入审计事件，让“哪一版规则批准了哪类变更”成为可追踪证据。

这对 AI Agent 尤其有意义：Agent 仍然可以高频修改对象，但能够放行写入的规则是有身份、有版本、有指纹的；策略代码变化后必须重新批准，不能静默继承上一版信任。

5. 用 E 表达式区分“空值”和“根本没加载”

Rust 的 Option 能表达“有值或为空”，但数据库投影还有第三种状态：字段或关联根本没有被查询。若把后两者都当成 None，程序可能把一个漏写 select 的编码错误误判成正常业务空值，并继续产生错误结果。

TQ 根据模型生成 E 表达式，保留三种状态：

• Value(value)：字段已加载且有值；
• Null：字段已加载，业务上确实为空；
• NotLoaded：查询没有预加载该字段或关联，是程序错误。

例如读取 Asset 的 Blob 关联和路径时，查询端必须先明确选择要遍历的关联，然后再用 E 读取：

let assets = Q::assets()
    .select_self_fields()
    .select_asset_blob()
    .with_id_is(asset_id)
    .limit(1)
    .comment("what: load one asset and its blob metadata")
    .purpose("why: verify package content before download")
    .execute_for_list(context)
    .await?;

let asset = assets.into_iter().next().expect("asset exists");
let blob = E::asset(&asset).get_asset_blob().eval();
let path = E::asset(&asset)
    .get_path()
    .or_if_null("unknown-path".to_owned());

eval() 会把已加载的值或空值转换成 Option，但遇到 NotLoaded 会带着缺失访问路径立即失败；or_if_null(...) 也只为真正的数据库 NULL 提供默认值，不会掩盖漏加载。

当前模型生成的 E facade 已覆盖 Asset 的标量、ContentRepository 和 AssetBlob 前向关系。项目现有手写 Service 对 select_self_fields() 后的标量仍采用直接 accessor，尚未把跨关系读取迁移到 E::；所以上面的代码展示的是已经生成并验证过的安全访问能力，而不是声称所有业务路径都已完成迁移。后续涉及最小投影和跨关系遍历时，优先使用 E 表达式，可以让“数据为空”和“程序写错了查询”保持清晰边界。这种尽早失败比在很远的业务分支里产生错误制品元数据更容易定位，也更适合 Registry 这类基础设施服务。

5 秒启动

镜像和 .env 已准备好时，启动只有一条命令：

docker compose up -d

服务端和 TUI 都是 Rust 编译出的独立二进制，没有 JVM 或脚本运行时的预热过程；在本地或集群节点热启动时，应用进程通常可以在数秒内进入工作状态。这里的“5 秒”指应用自身的启动体验，首次拉取镜像以及等待 PostgreSQL、S3 就绪的时间仍取决于网络和部署环境。

首次部署只需先准备仓库和环境变量：

git clone https://github.com/teaql/teaql-registry.git
cd teaql-registry
cp .env.example .env
# 在 .env 中设置 POSTGRES_PASSWORD 和 S3_SECRET_KEY
# 然后执行上面的 docker compose up -d

启动后可访问：

• Web Console：http://localhost:8081/
• REST API：http://localhost:8081/service/rest/v1/...
• Prometheus Metrics：http://localhost:8081/metrics
• 快速帮助：http://localhost:8081/help

TUI 可以这样运行：

cargo run -p registry-tui -- \
  --endpoint http://localhost:8081 \
  --username admin

管理员初始密码默认随机生成并写入凭据目录，也可以在首次启动前通过 ADMIN_PASSWORD 显式设置；项目没有内置默认密码。

当前状态与我们希望得到的反馈

仓库已经有 workspace 测试、协议生命周期测试和覆盖多个生态的原生客户端验证。不同生态的边角兼容性仍然很多，尤其是代理/聚合仓库行为、签名元数据以及各版本客户端差异，这些正是我们接下来希望继续打磨的部分。

如果你正在做 AI Agent、内部构建平台、离线开发环境，或者只是对“用 Rust 实现多协议 Registry”感兴趣，欢迎试用、提 Issue 或 PR。我们尤其希望听到下面几类反馈：

1. 你最常用、但目前还缺失的开发制品格式；
2. Proxy / Group 仓库在真实团队里的使用方式；
3. 跨平台预编译工具链的命名、索引和分发体验；
4. 哪些协议值得优先补齐更严格的官方兼容测试。

项目地址：https://github.com/teaql/teaql-registry

许可证：Apache-2.0

rivet 是一个开源 Rust CLI，从 OLTP 数据库读取变更并写入数仓。作者完成了第一轮生产试点：MySQL 由 rivet 直接读 binlog，写成 Parquet 后放到 Google Cloud Storage，再进入 BigQuery。链路上是一台虚拟机加 cron，不经过 Kafka、Debezium 或 Airflow。

试点库有 154 张表、32 亿行，每天刷新 8 次。原管道用日期窗口拉取变更，每周再全量重载一次；没有 updated_at 变化的修改要等到周重载才会被看见。对照同一数据库上的原管道：第一天发现 880 行事后被改过、但时间戳没动的记录，抽查后确认是过期余额。MySQL 副本读负载约降 99%，每月约 4 TB 读取（其中约 95% 来自每周全量）变成约 24 GB binlog 流。AWS 到 GCP 出站流量约降 98%，每天约 150 MB 压缩 Parquet，不再每周传整库快照。BigQuery 的 MERGE 作业少 25%，每次 MERGE 的字节少 30%。同等刷新频率下，BigQuery、GCS 与出站合计基础设施成本约降 50%。存储变化约在 ±2%。

完整一轮目前约 68 分钟：读完全部 154 张表的 binlog 约 9 分钟，其余是逐表加载和合并。日志里 BigQuery 忙碌时间约占 25%–30%。作者估计升级到最多 16 张表并行后，一轮可能到 10–25 分钟，试点升级后的数字还没测完。仓库：panchenkoai/rivet。说明页：https://panchenkoai.github.io/rivet/cheat-sheet.html

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

用 Iced 重写整个界面

Git Cherry Tree 是一个用 Rust 写的 Git 客户端。作者把原先的 Tauri + React 界面换成 Iced。

换之前，Linux 上的 Tauri 构建大约 90 MB，也不能像 Windows 那样直接发一个免安装二进制。Windows 上跨进程调用的延迟至少 3 ms。Tauri command 大约 2–10 MB/s；一次传很大的负载大约 100 MB/s，传输期间界面会卡住；绕过 Tauri command API 的内部下载协议大约 40 MB/s。有杀毒软件把启动浏览器这一步报成诈骗软件。

换完后，界面代码从约 2.4 万行 TypeScript 增到约 4.5 万行 Rust，其中包含为了打磨效果而放进仓库的一部分 Iced 组件。二进制从 Web 版的 15 MB，到第一版 Iced 的 8 MB，功能补齐后到 23 MB，再压回 15.3 MB；若把 panic 设为 abort，大约还能到 11 MB。高负载下帧时间从约 9 ms 降到 3–6 ms。Linux 上可以打成单个可运行二进制。作者自写了一个只生成着色 span 的语法高亮，支持 30 多种语言、70 个文件扩展名；百万行 diff 从点击到显示大约 700 ms，大约比 Web 版快 3–4 倍。图标没有用完整 SVG 渲染器，那个依赖大约会增加 3 MB。

原文链接：https://www.gitcherrytree.com/blog/rewriting-the-ui-in-rust/

用 Rust 写 Linux 内核模块

这是一篇在 Ubuntu 26.04 和 Raspberry Pi 4 上搭建 Rust 内核模块开发环境的记录。目标是给 Pi 4 上的 16x2 LCD 写驱动；本文只写环境，下一篇给驱动规格和最小示例。环境按 2026-09-27 在 Ubuntu 26.04 LTS 上验证。

Raspbian 内核默认没有打开 Rust。作者按树莓派文档交叉编译内核，并关掉与 Rust 不兼容的 CONFIG_MODVERSIONS。模块目录里把 rustup 工具链固定到 1.93.1 后，交叉编译出的 hello_rust.ko 可以在 Pi 上 insmod，dmesg 打出 Hello from Rust! 和 Goodbye from Rust!。本机 Ubuntu 构建则不用 rustup：需要 apt 安装 rust、rust-src 和与当前内核版本对应的 linux-lib-rust-$(uname -r)，并且不要加 LLVM=1，因为 Ubuntu 预编译内核走的是 gcc。作者注明 Hello Rust 示例里有一部分代码来自 Gemini，Makefile 做了小改。

原文链接：https://thehecknow.hashnode.dev/implementing-a-linux-device-driver-in-rust

cargo-crap 0.6：给重复函数做类型化分级

cargo-crap 是用来找出 Rust 代码里重复函数的命令行工具。0.5.0 的 --duplicates 用 syn 把函数解析成树，抹掉函数名、变量名、字段名、路径名和字面量，再按子树指纹的 Jaccard 相似度比较。默认阈值 0.82。在作者自己的源码上，这一步报出 24 对，其中既有改名后的同一段逻辑，也有只是都调用了 writeln! 的相似形状。

0.6.0 增加可选 triage：把每一对函数体和相似度发给 TypeSafe 的 System One 模型（默认 jev-latest），返回四种类型之一（same-logic、parameterisable、shared-shape-only、structural-obligation）、是否值得合并，以及一边修 bug 另一边会不会漏修的概率。置信度默认低于 0.5 时只标 uncertain。结果缓存在 target/，键包含两边函数体、模型和问题集的哈希。triage 只加注释，不改变退出码；没有密钥、没有网络或某一对请求失败时，整段分级会被丢掉，退回原来的结构报告。默认关闭，要在 .cargo-crap.toml 里打开，并且环境变量里有 TYPESAFE_API_KEY。发布二进制自带该功能；从源码安装需要 --features triage。

原文链接：https://minikin.me/blog/cargo-crap-triage

From Rust中文社区 Mike

社区学习交流平台订阅：

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

这是一篇对 Polars 并行执行的性能剖析，记录一个 profiling 周期里的第一批发现。测试机是 24 核 / 48 线程的 Intel Xeon Gold 5412U，负载用 TPC-H；scale factor 30 时 lineitem 约 1.8 亿行，orders 约 4500 万行。

一条 count(*) ... where l_comment like '%special%' 在 1 线程上约 20.6 秒，24 线程上约 2.76 秒，加速大约 7.5 倍。过滤被下推到 Parquet 读取。正则库用缓冲池借出 scratch 内存：池里有一个免锁槽留给最先用到该正则的线程，其余线程走互斥锁。Polars 把同一个正则对象交给每个解码线程后，其余 23 个线程会堵在借还缓冲上。修复是给每个线程一份自己的正则。8 通道内存机器上，like '%special%' 从 2544.0 ms 降到 1085.9 ms（-57.23%，6/6 轮），like 'the%' 从 1835.3 ms 降到 677.8 ms（-62.85%）；24 线程扩展从约 8.6 倍升到约 20.4 倍，单线程时间基本不动。

同一周期里，窗口函数也出现空转。同样约 1.8 亿行上，sum() over (partition by ...) 约 2617 ms、约 23.06 核忙碌；带 order by 的 row_number() 约 50492 ms、约 2.29 核忙碌。组数很少时，组内排序只占少数线程。顶层调用在组数少于线程数时改走 Rayon 并行排序后，3 个分组的查询从 20402 ms 降到 10557 ms（约 -48%），50 个分组的对照查询保持持平。

原文链接：https://abokhalill.github.io/missing-cores-part-1/

fframes 1.0：用 Rust 和 SVG 在 GPU 上渲染视频

fframes 是用 Rust 写视频、用 SVG 描述画面、再在 GPU 上渲染的视频框架。作者在 r/rust 宣布该项目约五年后发布 1.0。每一帧由 Rust 函数通过 svgr! 宏返回一棵 SVG 树，静态片段在编译期哈希并缓存。GPU 后端用 Skia：macOS 走 Metal，Linux / Windows 走 Vulkan。仓库说明该后端约比内置 CPU 后端快 10 倍。编码直接链接 ffmpeg 的 libav 库。SVG 不够时可以叠 SkSL 或 Shadertoy GLSL shader。

仓库示例称一段 128 秒视频渲染耗时 36 秒。命令行可以导出时间轴、抽帧、接触表和音量分析，并写出 mp4；render --draft 用半尺寸编码单个场景。crate 名为 fframes，仓库为 dmtrKovalenko/fframes。

原文链接：https://github.com/dmtrKovalenko/fframes

Philbin：带运行时 CPU 探测的纯 Rust AEGIS 库

Philbin 是 AEGIS 认证加密算法的纯 Rust 实现，crate 名 philbin。AEGIS 是 CAESAR 竞赛获胜算法之一，对应规范为刚发布的 RFC 10032。文章称，在有 AES 硬件加速的 CPU 上，它快于 AES-GCM 和 ChaCha20-Poly1305。作者说明这是目前唯一用运行时 CPU 探测分发到对应 SIMD 实现的纯 Rust 版本：普通 release 二进制覆盖 x86-64 与 AArch64，并带软件回退，不需要 target-cpu=native。

实现里 unsafe 块一共两行，用 CPU feature token 做编译期和运行期检查。测试包含 IETF 与 Rooterberg 向量，并相对 libaegis 做差分 fuzz；另有 TVLA harness 检查与密钥相关的非常量时间。API 分成 easy 和 careful。easy 内部处理 nonce，使用操作系统 CSPRNG，默认 256 位认证标签和 AEGIS-256X4。库会拒绝全零密钥和全零 nonce。仓库：Valloric/philbin。

原文链接：https://val.markovic.io/articles/philbin-the-safest-and-fastest-aegis-library

Rust 领导理事会九月更新

这是 Rust Leadership Council 自 7 月 6 日更新以来的工作说明。9 月代表选举结果：Infrastructure 仍由 Jakub Beránek（@kobzol）代表，Language 由 Pete LeVasseur（@PLeVasseur）代表，Library 由 Mark Rousskov（@Mark-Simulacrum）代表，Moderation 仍由 Oli Scherer（@oli-obk）代表。离任代表是 TC 与 Josh Triplett。下一轮代表选举在 2027 年 3 月。

理事会已启动两名 Rust Foundation 项目董事选举，提名已收集，投票在 10 月进行。Funding 团队在此前 5 万美元之外再获 12 万美元，与 Rust Foundation Maintainers Fund 一起支持了 7 名贡献者，其中 5 名 Maintainer in Residence、2 名 Maintenance Grantee。项目优先级预算改为当年预算当年用完。Mentors 团队的 2026 年 12 月 Outreachy 轮次追加 3.2 万美元。差旅预算在原有 10 万美元之外再追加 32325 美元。

rust-lang/rust 仓库已有正式 LLM 政策，多个相关仓库跟进。理事会决定新建 LLM policy 团队，负责项目级政策与后续更新。理事会观察员政策已更新。Rust Foundation 已全职聘用此前由项目优先级预算资助的 Tomáš Šedovič，担任项目经理。此前负责撰写理事会更新的 Eric Huss 已离开理事会。

原文链接：https://blog.rust-lang.org/inside-rust/2026/09/28/leadership-council-update/

From Rust中文社区 Mike

社区学习交流平台订阅：

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

几个 pane 里各跑一个 agent 的时候，想让它们配合起来很麻烦，就慢慢往这个方向做了。现在大概有这些：

1. pane 之间通信。每个 pane 有自己的收件箱，可以从一个 pane 给另一个 pane 发消息，或者让它执行一条命令，结果和输出之后都能查到。pane 有三种模式：手动模式，消息先放着，程序自己来取；shell 模式，收到就当命令执行；ai 模式，交给里面的 agent 处理。
2. 跨机器通信。两台电脑在同一个局域网，或者都连着 tailscale，配对一次（和 ssh-copy-id 差不多，之后就不用再管密钥了），一台上的 pane 就能给另一台上的 pane 发消息，回信会回到发消息的那个 pane。也能看对方机器的状态，看命令在那边跑得怎么样；对方同意的话，还能看它某个 pane 的屏幕。安全上我做得比较保守：对方发来的消息默认只交给 agent，想让它在 shell 里直接执行，得你自己在本机手动打开，pane 里的 agent 开不了这个权限。
3. MCP。agent 可以通过 MCP 自己开 session、开 pane、给别的 pane 发消息，另一台电脑上的也可以。
4. 手机上控制。扫码就能看到所有 session、window 和 pane，也能往里发命令，命令还是在电脑上跑。pane 可以调成手机屏幕的大小，看全屏的程序会方便一些。
5. dashboard。可以看每个 pane 现在在做什么、之前做过什么，收件箱和任务也在里面。
6. 剩下的和 tmux 一样。关了终端，pane 里的程序还在跑；电脑重启以后，用 keepane resume 能把 session 恢复回来；原来的 .tmux.conf 可以用 keepane import-config 导进来。

安装的话，macOS 和 Linux 用 brew install newdee/tap/keepane；Windows 用 scoop（scoop install https://raw.githubusercontent.com/newdee/keepane/master/packaging/scoop/keepane.json），或者去 Release 下载 MSI、zip。装了 Rust 工具链的话，也可以 cargo install --git https://github.com/newdee/keepane --locked。

还在一直改，肯定有很多没考虑到的地方。欢迎试用，也欢迎提 issue 或者直接在这里回复。

项目地址：https://github.com/newdee/keepane 详细介绍：https://dfine.tech/posts/626063bd/

最近新增了一下[子网路由]的功能。主要场景是支持组网内的节点通过路由转发的能力去访问内网环境的服务。

Noeio 是我之前写的一个 3 层轻量级无状态的组网工具，其实和 Tailscale 类似，这个项目的初衷还是出于学习的目的。主要是分享一下，同时探索一下能否在 Sandbox 中有更好的应用场景，AI 时代感觉未来这种组网互联的需求应该蛮旺盛的

下一步：

1. 实现一下 port-forward 端口转发的能力

GitHub：https://github.com/noeio-net/noeio-core 子网路由介绍：https://noeio.net/zh/guides/intranet-gateway

PolyXOR128 是用 Rust 实现的 128 位通用哈希（universal hash），面向文件/数据流完整性校验，并强调密码学强度下的低碰撞概率。作者 orlp（此前有 polymur-hash、foldhash 等）发布仓库 orlp/polyxor：在密钥与输入独立且随机的前提下，长度至多 n 字节的两条消息碰撞概率上界为 (n/4096 + 3) / 2^128，证明用 Lean 完整形式化。

吞吐上，作者在中大型输入上对比 crates.io 常见实现：除 CRC64 外快于所测主流哈希；在带 AVX-512 的机器上 bulk 吞吐可接近 foldhash 的约两倍。单线程示例数据包括 Ryzen 9950X 最高约 130 GB/s、Apple M2 Pro 约 60 GB/s，并给出 Xeon 等图示。实现依赖硬件加速的无进位乘法（carryless multiply），对 AArch64 / x86-64 做动态分发；便携参考实现极慢，嵌入式可能受限。密钥展开实例约 5 KB 内存；小串（如 ≤256 字节）目前零填充到 128 字节倍数，尚未专项优化。

通用哈希要求密钥对数据保密且不公开；跨不安全信道应使用 finalize_mac（用 AES 封装哈希）再传输。它不能替代无法保密密钥时的抗碰撞哈希（例如公开包校验和）。设计上对 128 字节块混入密钥、奇偶扩展后做类似 CLHASH 的 NH 变体，SIMD 累加后再进入多项式归约；另有 design.md。作者说明正文与最终代码主要为人工撰写，Lean 形式化由 AI 生成但结论经其核验且可被 Lean 检查。相关帖曾被误判为非人工后已由版主恢复。

原文链接：https://github.com/orlp/polyxor

Casita：面向源码与构建产物的内容寻址存储层

Casita 是 Cachix 团队在用 Rust 重写 Nix、并按层拆分现代化时交出的第一层独立组件：内容寻址对象存储，覆盖共享存储、校验、同步与垃圾回收，以 Rust 库和 CLI 预发布，目标平台 Linux / macOS / Windows。背景是 agent 开发会更快堆出多版源码与 target/ 产物，全留占盘、全丢又要重编。

存储模型类似广义的 Git 对象库：不可变 blob 与不可变对象记录；blob 用完整字节的 BLAKE3，并可附带 Bao outboard 做区间校验。目录/文件等记录在 blob 之上形成图；改文件会换新 ID 并向上传播，未改文件共享原 blob。应用通过 root 命名保留可达图；可重建数据（如 Cargo target/）可用 evictable root。导入支持文件系统、tar、NAR 与 Git；Casitar 可打包完整图；另有实验性 Gix ODB 适配、CasitaFS 只读挂载（Linux FUSE / macOS FSKit），以及本地与可选 SSH 同步。共享 S3 后端仍实验性。

团队还在 Cargo 上加了 ArtifactStorage 接口与 Casita backend（实验分支），用于 registry/Git 依赖与 workspace 构建产物的导入恢复，目前性能尚未追上文件系统后端。0.1 前仍需压测、拓宽基准与真实工作流验证。仓库：cachix/casita。

原文链接：https://casita.rs/blog/introducing-casita-a-content-addressed-store-for-source-code-and-build-artifacts/

mbrotli 进入上游 lzbench：安全 Rust 实现的 Brotli 可对照官方基准

mbrotli 是用安全 Rust 编写的 Brotli 编解码器。此前多数对比数据主要来自项目自有仓库；现在 mbrotli 0.5.2 已进入上游 inikep/lzbench（PR #333），可与 Google Brotli 等编解码器在同一 harness 下跑分。

作者在 WSL2、默认 lzbench 构建、window 22、单线程、Silesia 语料上对比捆绑的 Google Brotli 1.2.0：解压在各 quality 上 mbrotli 更快（约 1.09–1.16×）；q0–q1 压缩基本持平或略快；q2–q9 压缩目前约慢 1–9%；q10 / q11 压缩显示约 1.18× / 1.35× 更快。q0–q9 压缩体积一致；q10/q11 的微小体积差来自 lzbench 对 C Brotli 使用了 -ffast-math，会改变最高 quality 下的浮点代价计算，按常规方式构建 C Brotli 后输出可再次对齐。作者强调不必过度解读 q10/q11 对比，但进入上游 lzbench 后可以用公共基准继续看优势与短板。

原文链接：https://github.com/inikep/lzbench

Taipei：与 Tower 集成的服务过载治理，附交互式说明

Taipei 是与 Tokio Tower 集成的库，目标是让服务在压力下仍表现稳定，并减少手调。功能以 Tower layer 形式提供，可包在已有 Service 外；文档站点用 WASM 跑真实 crate，配合交互仿真讲解过载相关原则，即使不直接用该 crate 也可作参考。

示例路径包括：用 InstrumentedTokioRuntime 观测 CPU；CpuBackpressureLayer 在 CPU 高于阈值时托住请求；QueueLayer 做排队与超时，并把队列错误映射为 HTTP 503 等。文档从手写并发上限讲起，说明为何需要队列、背压与运行时观测，再对比“拍脑袋 limit”的局限。仓库：nhawkes/taipei；说明入口：https://taipei-book.pages.dev/intro 。作者注明文案自写，代码有 AI 辅助。

原文链接：https://taipei-book.pages.dev/intro

From Rust中文社区 Mike

社区学习交流平台订阅：

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

怎么用

• /voice：说一段，停顿一下自动收尾，转写结果落进输入框。
• /voice ptt：按住空格说话，页脚有实时电平条，松手发送。
• /voice auto：免手操，它读完麦克风自己开，你打字就暂停。

你敲键盘就取消，识别错了可以先改。回复会用 Edge TTS 读出来，朗读前把 Markdown 剥掉，不会念一堆星号和 URL。你一打字或按 PTT，正在播的立刻静音。

转写用的是 SenseVoice（sherpa-onnx 静态链进扩展），支持中英日韩粤，自动判语言，自带标点。模型约 240MB 放在 ~/.rpi/agent/models/sense-voice/，首次使用自动下载。 朗读使用Microsoft TTS 默认音色 zh-CN-XiaoxiaoNeural，/voice set zh-CN-YunxiNeural 换男声。

装起来

装 rpi（单二进制，挑一个）：

curl -fsSL https://raw.githubusercontent.com/bigfish1913/pi-rust/main/scripts/install.sh | sh   # 预编译，Linux/macOS
cargo install rpi-cli                  # 从 crates.io，需要 Rust 1.78+
brew tap bigfish1913/tap && brew install rpi     # macOS(ARM)/Linux
scoop install rpi                      # Windows，先 scoop bucket add bigfish1913 https://github.com/bigfish1913/scoop-bucket

装 rpi-voice，想全离线就得自己编译（原生库塞不进默认包）：

开箱即用 rpi install rpi-voice

跑起来：rpi，然后 /voice model download 预取模型，/voice ptt 开按住说话，/voice status 看输入设备和当前音色。

跑长任务的时候用 /voice auto 追加约束，改完一段让它读一遍当听觉 review，写 diff 描述直接口述

仓库在 https://github.com/pi-rust/rpi-package，扩展在 packages/rpi-voice/，命令和环境变量的完整清单在那边 README 里。

目前package 支持扩展 。欢迎大家PR和star https://github.com/bigfish1913

Qt 公司博客介绍 Qt Bridges 面向 Rust 的公开 beta：在保留 Rust 业务代码的前提下，接入 Qt Quick 的 UI 能力、硬件加速与跨平台支持（Linux / macOS / Windows）。目标是把汽车仪表、医疗与工业场景已验证的 Qt 成熟度提供给 Rust 开发者；相对 Iced、egui 等仍在生产落地中的框架，强调功能完整度与商业支持。

此前生态里有 qmetaobject-rs（QML + Rust，现偏维护状态）与 CXX-Qt（更适合已有 C++ 团队）。Qt Bridge 侧重“只写 Rust”：不直接碰 C++ 头文件与手工 FFI，UI 用 QML（可辅以 JavaScript），业务侧通过属性宏与 trait 的精简 API 交互。QML 对象在 Rust 侧以 Rc<RefCell<T>> 共享引用暴露，借用规则在运行时检查；编译期为 Rust 类型生成 Qt 包装，负责对象创建、方法调用、属性访问与 signal 等。用户代码本身无 C++，但当前版本构建仍需本机 C++ 工具链与 qmake；官方计划通过预编译产物等方式减轻该要求。用法上在 Cargo.toml 加 qtbridge 依赖，用 #[qobject] / #[qslot] 等标注后即可在 QML 中引用。示例仓库：qt/qtbridge-rust-examples。路线图是向 Technology Preview（TP）推进。

原文链接：https://www.qt.io/blog/rust-ui-framework-via-bridging-technology

rust-mqtt 0.6.0：嵌入式向 MQTT 客户端补齐 MQTTv5

rust-mqtt 是面向 no_std 的异步 MQTT 客户端，I/O 基于 embedded_io_async；当前以 MQTT 5.0 为主。作者约一年前接手无人维护的项目并重写，半年前曾发帖说明进展；0.6.0 补齐此前缺失的 MQTTv5 能力，重点是完整的增强认证（enhanced authentication），并加入手动/延迟确认（manual acknowledgments）。

设计上尽量用类型系统贴近规范：会话状态、配置、QoS 投递与重试由用户掌控，不做自动重连、keepalive 循环或后台任务等意见化连接管理，提供可取消安全的协议原语，适合上层客户端与资源受限嵌入式。已覆盖 Will、QoS 0/1/2 双向发布、流控、会话恢复、主题别名、共享/通配订阅、消息过期、Request/Response、User Property 与增强认证等。已知限制包括单包多主题订阅尚未支持、有序主题保证未内建（单 packet id 并发时约束可放宽）。后续计划包括 MQTT 3.1.1、更灵活的内存与 I/O，以及在坚持 no_std/no_alloc 主目标的同时改善 std/桌面体验。

原文链接：https://github.com/obabec/rust-mqtt

Moxy：面向过程宏的 Rust 语法工具栈

Moxy 是一套面向过程宏的 Rust 语法工具，覆盖 token、类型化语法树、模板、格式化与诊断。作者此前发布过过程宏模板引擎 zyn，社区反馈希望少依赖 syn / proc-macro2 / quote；Moxy 从零重写，非可选外部依赖目前主要是 unicode-ident，其余核心语法栈自研。

目标包括：依赖尽量少；性能上与 syn 对标（作者基准里 compile time 仍偏 syn，runtime 有时 Moxy 更好，目标并非全面超越）；用自维护 EBNF 与系统化 grammar fixtures（attributes、表达式、泛型、items、宏、paths、patterns、语句、类型、可见性与 lexer 等）持续校验解析覆盖；保留 zyn 风格的模板/paste 类准引用；并类似 proc-macro2 同时支持 stable 与 nightly，以便在 stable 上提供编译器诊断能力。功能按 feature 分层（token/ast/template/fmt/diagnostic 等）。项目仍早期、API 会变，作者欢迎语法覆盖与架构反馈。仓库：https://github.com/aacebo/moxy

原文链接：https://github.com/aacebo/moxy

module-cycles：用 Dylint 检测兄弟模块循环依赖

module-cycles 是一个 Dylint lint，用于报告“兄弟模块”之间的循环依赖。Clippy 自 2020 年起有相关 issue（#5782）尚未落地，作者据此实现。兄弟模块指共享同一父模块的子树；若 model 与 report 彼此引用则告警。父子互用（把一个模块拆成多文件）不报。依赖来自 rustc 名字解析结果：路径、use/re-export、方法调用与关联函数都算；外部 crate 宏展开的引用会跳过，本 crate 宏写出的引用会计入并标在调用点。

每个环只报一次，并 note 最短环上的其余边；建议把共享项挪到其中一侧或双方共同依赖的模块。作者在自己的 workspace 扫到 11 个环（最长经 12 个模块），在 Clippy 测试用的 26 个 crate 上扫到 41 个（含 tokio）。通过 workspace metadata 挂 Dylint library 后执行 cargo dylint；可用 DYLINT_RUSTFLAGS="-D module_cycles" 把警告升为失败。

原文链接：https://github.com/HardMax71/module-cycles

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() 方法中，是确保数据完整性和系统高可用性的关键。