它不是又一个“套了湖仓壳”的存储系统，而是把本体语义、多模存储、推理能力真正沉到内核里的下一代数据底座：数据落库即完成实体对齐、关系推理与语义标注，从“原始堆积”直接变成“AI-Ready”。

为什么是 OntoLake

传统湖仓解决的是“文件像表一样可靠”，OntoLake 多了一层别人没有的东西：

本地文件当湖、实体表当仓、本体当语义内核、向量当 AI 接口；

结构化、图、向量、时序、文档、空间统一存储，不再多库搬运；

写入即推理，subClassOf、等价类、传递关系自动展开，查询不再靠应用层硬编码。

关键进展：已打通 DuckDB 与 Trino 读取

这一次，OntoLake 完成了与两条主流分析引擎的读取打通：

DuckDB：进程内嵌入式分析直接读 OntoLake 语义表，适合笔记本、边缘节点、Python 工作流里的秒级探查；

Trino：分布式联邦查询接入，多机集群、跨源 JOIN、BI 工具直连，把 OntoLake 当成一等公民目录。

这意味着：分析师用 DuckDB 做本地深挖，平台侧用 Trino 做全局编排，而底层语义、口径、血缘都由 OntoLake 统一托管——查出来的不是“字段”，是“含义”。

对业务意味着什么

生物医药：查“EGFR 抑制剂”自动展开全部子类，不用维护枚举列表；

工业/城市：端侧语义摘要进湖，跨域仲裁结果可溯源、可重放；

AI 应用：GraphRAG、Agent 记忆、语义检索直接消费“已治理好的知识”，而不是先洗数据再推理。

......

OntoLake 的发布，不是多一个组件，而是把“数据湖仓”重新定义为语义数据基座。

DuckDB 与 Trino 的打通，只是开放生态的第一步。

数据先语义化，再谈智能化。OntoLake 和更多朋友一起出发。

这是一篇评 GPUI 状态模型的文章，作者是 Zortax_。文章比较 immediate、Elm、view 和 signal 这几类做法，看一个值变化以后哪些代码会重跑。Reddit 采集时 301 分、81 条评论。帖子时间是 2026-11-09 02:29 UTC。

作者在文首写了两件事。Discord 宣布用 GPUI 重写客户端。不少 LLM 客户端选了 egui。作者认为这两套状态模型撑不住复杂桌面应用。Zed 用起来快，作者自己也在 Bevy 游戏里用 egui 做调试界面。文章同时写明，作者把 GPUI 当前的 Linux 渲染器移植到了 wgpu，下面的基准测试套件是作者搭的，作者还在做信号式框架 zgui。zgui 仓库在 https://github.com/zortax/zgui 。采集时 214 星、6 个 fork，许可证 Apache-2.0，最近推送是 2026-11-08。Zed 仓库采集时 94598 星、11595 个 fork。

GPUI 自述是 immediate 和 retained 的混合。状态留在 entity 里，界面写在 render 函数里。改状态要显式调用 cx.notify()。notify 带的是 entity id。Rust 的 &mut 没有写屏障，GPUI 看不到改了哪个字段，也看不到有没有真的改动。没有有效 .cached() 边界的 view 会重跑。文章写，应用作者很少用 .cached()，这个缓存对布局语义还有限制，实际经常是每个 view 都重跑。

文章里的数字是稀疏更新的成本。3000 个存活行，每行一个带缓存的 view，改一个标签要 8.4 ms。每多 1000 个存活行，大约再加 3 ms。悬停、按键、写成原值，成本接近，因为成本跟着整棵树走。行如果写成普通元素，同一个标签要 92 ms。手写相等判断以后，写成原值的耗时从 7.9 ms 降到 0.9 µs。

文章接着写，把更新做得更细，会把 GPUI 现在这套 API 拆掉。Longbridge 的 gpui-fast 会在帧之间保留每个 view 的子树。3000 行那个标签从 8.4 ms 降到 3.4 ms。能复用的最小单位仍是 view。要让一个标签单独更新，这个标签自己得是一个 view，带 entity、Render、订阅、一份存下来的值和手写判断。状态归每个 panel 自己管时，一次改动能省 83%。状态改成共享模型以后，同样一帧的 retention 慢 11%。窗口和编辑内容没有变。Zed 团队测到，retention 在普通负载上比关掉慢 1% 到 3%，微基准的收益对不上真实 Zed。Zed 自己的说法是，一个窗口有几十个节点和几千个元素。文本编辑器是自定义元素，绕开了 GPUI 的布局和 view 语义。

nicoburns 的评论有 45 分，问能不能把 Dioxus Native 加进这组基准，并希望看到可运行的基准代码。作者回复有 22 分，写 harness 里已经有，文中数字是 taffy 那次更新之前的一次运行，这周会整理对比仓库。zenware 的评论有 81 分，写不喜欢 React 式模型，但拿掉浏览器引擎以后，就算状态模型还像 React，内存和延迟也会下来。作者回复有 58 分，写浏览器的主要成本在 JS、DOM API、线程模型和进程隔离。GPUI 应用的内存、二进制体积和延迟下限会马上下来。作者同时写，随便写的 GPUI 应用会比随便写的 SolidJS 网页应用更顿。simspelaaja 的评论有 46 分，写文章里有多处 LLM 用语，主题有内容，但分不清哪些句子是作者写的。imbev 的评论有 66 分，写 Elm 回答的是发生了什么，View = f(State) 里的函数可以做成纯函数。作者回复有 25 分，写没有显式的 read 绑定，就只能靠 diff 把新的 view 对上保留下来的渲染状态，这个 diff 是 O(n)。

原文链接：https://blog.zortax.de/posts/a-critique-of-gpui

Cot 0.8 补上事务和迁移回滚

Cot 是一个 Django 风格的 Rust Web 框架，自带 ORM、管理后台、表单、认证和 session。0.8 的发布说明写于 2026 年 11 月 9 日。仓库在 https://github.com/cot-rs/cot 。采集时 1095 星、60 个 fork，许可证 Apache-2.0，最近推送是 2026-11-09。crates.io 上的包名是 cot，当前版本 0.8.0，更新时间 2026-11-09，累计下载 26243，近期下载 2984，16 个版本。Reddit 作者是 m4tx，采集时 6 分、0 条评论。帖子时间是 2026-11-09 23:40 UTC。

ORM 这一版加上事务。Database::begin 开一个事务，后面的 insert、save 和 query! 可以把这个事务当成原来的数据库来传。事务对象在没有 commit 的情况下被 drop，会自动回滚。在事务上再调用 begin，得到的是 savepoint，可以单独提交或回滚。

查询补了排序和文本匹配。order_by 接受一组字段或表达式，各自带 asc 或 desc，还可以用 nulls_first、nulls_last 和 by_values。query! 增加 contains、starts_with、ends_with，以及忽略大小写的 icontains、istarts_with、iends_with。用户输入里的 % 和 _ 会按字面量转义。raw_like 接受 "PKG*US" 这种 glob，再按后端翻译。复杂查询可以走原始 SQL：raw 和 raw_with 执行不返回行的语句，raw_as 和 raw_as_with 把行映射成模型。带 _with 的版本会绑定参数。

迁移可以回滚。cot migration rollback 0002 --dry-run 只打印计划。指定的迁移本身留着，它后面的迁移会被撤掉。跨 app 的依赖会一起撤，比如另一张表的外键指过来。也可以传完整迁移名，或者传 0 撤掉这个 app 的全部迁移。cot migration graph --format mermaid -o migrations.mmd 导出依赖图。

路由器用 matchit 的 radix trie 重写。构建时会拒绝 /foo/{bar} 和 /foo/{baz} 这种有歧义的路由。{*path} 可以匹配剩余路径。reverse! 可以追加 query，值会做百分号编码。新项目默认启用 TrailingSlashMiddleware，GET 和 HEAD 在原路径不匹配、补上斜杠能匹配时会重定向，query string 保留。Redirect::permanent 用 308，Redirect::temporary 用 307。ClientIpAddr 默认取直连对端地址。反代场景在配置里写可信网段和 header：

• proxies = ["10.0.0.0/8"]
• headers = ["x-forwarded-for"]

Reddit 发布帖写，这一版去掉 axum，改成直接用 hyper。帖子写，项目没有用到 axum 的高层功能，这次是为了减少依赖和编译时间。配置 TOML 的参考页从源码生成。随这次发布一起放出来的示例是 Hack the Space，地址是 https://hackthespace.mackow.ski/ 。1.0 之前还想要什么，写在 https://github.com/cot-rs/cot/issues/434 。

原文链接：https://mackow.ski/blog/cot-v08-lazily-transactional/

rust-analyzer changelog #353

这是 rust-analyzer 2026 年 11 月 9 日的 changelog #353。rust-analyzer 是给 IDE 用的 Rust 编译器前端。仓库采集时 16976 星、2284 个 fork，许可证 Apache-2.0，最近推送是 2026-11-10。Reddit 转发作者是 WellMakeItSomehow，采集时 29 分、3 条评论。帖子时间是 2026-11-09 15:40 UTC。评论里没有对上具体改动的内容。

新功能里，#21392 给 Linux glibc 发行版打开 jemalloc。#23600 是第一次贡献，加了一个选项，只对带 drop glue 的类型显示隐式 drop 提示。#23558 从欢迎页去掉 Create Rust Project 按钮。诊断新增三项：invalid-pat-path-res、match-inherited-imm-ref-with-mut-ref-pat、unresolved-associated-type，对应 #23583、#23589、#23619。性能项 #23591 对 lang item 做了微优化。

修复里，#23598 让 problem matcher 对上 rustc-unicode 的位置。#23478 和 #23631 补上类型位置的 dyn trait 补全。#23610 让强制转换逻辑对上 rustc。#23608 修了 MIR 求值 panic。#23579 不再给结构体字面量提示到不了的路径。#23615 修了 #[repr(i28)] 补全。#23620 让 destructure_struct_binding 可以作用在通配符模式上。#23592 让 generate_doc_example 可以作用在重导出项上。#23554 修了 move_bounds_to_where_clause 之后 GAT 约束的位置。#23616 修了 apply_demorgan 在类型转换上的 panic。#23602 修了 generate_function 在带泛型时的 panic。内部改动里，#23514 把 expect-test 合进 rust-analyzer 仓库。

原文链接：https://rust-analyzer.github.io/thisweek/2026/11/09/changelog-353.html

tellus 验证器 0 次违规，8 个请求失败

这是一篇讲 tellus 集群故障注入的文章，作者是 Heiko Seeberger。tellus 是跑在 Tokio 上的 actor 框架，带监督、有序 death watch、事件溯源和集群。仓库在 https://github.com/tellus-rs/tellus 。采集时 71 星、3 个 fork，许可证 Apache-2.0，最近推送是 2026-11-09。crates.io 当前版本 0.5.3，更新时间 2026-11-01，累计下载 635。Reddit 作者是 quest_for_7c，采集时 0 分、1 条评论。帖子时间是 2026-11-09 14:01 UTC。作者评论有 1 分，写两个 bug 都出在第一次带集群的发布之前。

演示用 Docker Compose 跑 5 个节点，节点通过同一个 DNS 名互相发现。前面放 Caddy，把 HTTP 请求分到这些节点。每一轮，脚本做一件事：杀掉一个节点，用 SIGTERM 停一个节点，或者把两个节点和另外三个隔开。退出或被杀掉的节点会重启并重新加入。集成测试已经会拉起真实进程，覆盖不到 DNS、容器重启和负载均衡。文章写，两个 bug 都出在这三处。

验证器不会在故障进行时检查成员关系。分区两侧看到的成员不同，这是对的。它等混沌停 30 秒，再检查一次是否恢复。恢复的定义是：每个节点都是成员，都把 5 个节点看成 Up，没有脑裂，每个节点都能找到别人的 actor 并向每个节点发消息。每个节点用 HTTP 提供自己的集群视图，验证器用普通 Rust 把 5 份视图拿来比较。

负载均衡要在故障期间继续应答，所以验证器一直查它。一次请求结束后等 0.5 秒再发下一次。连续失败超过 5 秒才记一次违规。每次失败的请求仍然单独计数。2026 年 10 月一次 45 分钟运行里，违规次数是 0，发出的 5352 个请求里有 8 个失败。

第一个 bug 是违规。分区之后，失败一侧的两个节点几乎同时把自己移出并重启。其中一个查共享 DNS 名时，另一个容器还没起来，所以只看到 4 个节点。tellus-bootstrap-dns 把这次应答缓存了，后面的查询还是旧列表。修复是一行：builder.options_mut().cache_size = 0。文章写，两个 bug 都在 tellus 0.4.0 之前修好，已发布版本不受影响。0.4.0 是第一个带集群的版本。

8 个失败请求对得上混沌日志。5 个紧跟在 kill 后面，3 个紧跟在优雅停机后面，分区后面没有。kill 丢一个请求不意外。SIGTERM 这条路径上，节点已经离开集群，健康检查却继续回 200，直到进程退出。Caddy 还在往它发请求，退出瞬间到达的请求失败。修复是进入 Leaving 阶段后健康检查回 503，并且至少再跑 5 秒，让 Caddy 看到变化。Caddy 也会把失败请求重试到另一个节点。带上这个重试以后，另一次 45 分钟运行里 5400 个验证请求都成功。

文章写，0 次违规不等于集群正确。这套故障没有模拟抖动网络、单向链路、时钟偏移和过载。录演示时终端 UI 在轮询每个节点，1552 个请求里失败了 1 个。去掉终端 UI 的 45 分钟运行没有再出现，原因还没查到。演示代码在 tellus v0.5.3 标签的 tellus-cluster-demo 里。

原文链接：https://heikoseeberger.de/2026-11-09-chaos-verifier/

From Rust中文社区 Mike

社区学习交流平台订阅：

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

English | 中文

数据库把一行数据交到应用程序手里之前，字符串通常已经被拷贝过好几次：从文件到缓存，从缓存到执行器，再从执行器到你的结构体。这篇文章讨论的是另一种可能：如果存储层是 LMDB 这样基于 mmap 的 KV 引擎，只读事务读到的页在事务结束前地址不变，那么 SQL 引擎能不能让查询结果一路借用这些页，让完整的 SQL 计算做到零拷贝？

Summary

SQLite 是应用进程内最常见的 SQL 数据库，在常见语言中都有稳定的绑定 API，这里以 Rust 的 rusqlite 为例。一个很常见的场景是：取出一个帖子下的全部评论，映射成结构体，按 parent_id 组装成回复树，再序列化成嵌套的 JSON 写给调用方：

use rusqlite::{params, Connection};
use serde::Serialize;
use std::collections::HashMap;
use std::error::Error;
use std::io::Write;

#[derive(Serialize)]
struct Post {
    id: i64,
    thread_id: i64,
    parent_id: i64, // 0 表示顶层评论
    user: String,
    body: String,
}

#[derive(Serialize)]
struct Comment<'a> {
    #[serde(flatten)]
    post: &'a Post,
    replies: Vec<Comment<'a>>,
}

fn build<'a>(children: &'a HashMap<i64, Vec<Post>>, parent: i64) -> Vec<Comment<'a>> {
    let Some(posts) = children.get(&parent) else { return Vec::new() };
    posts.iter()
        .map(|post| Comment { post, replies: build(children, post.id) })
        .collect()
}

fn write_thread(conn: &Connection, thread_id: i64, out: impl Write) -> Result<(), Box<dyn Error>> {
    let mut stmt = conn.prepare_cached("select id, thread_id, parent_id, user, body from posts where thread_id = ?1")?;
    let mut rows = stmt.query(params![thread_id])?;
    // 建树要等所有行到齐，而 row 只活到下一次 next，所以 Post 只能拥有 String
    let mut children: HashMap<i64, Vec<Post>> = HashMap::new();
    while let Some(row) = rows.next()? {
        let post = Post {
            id: row.get(0)?,
            thread_id: row.get(1)?,
            parent_id: row.get(2)?,
            user: row.get(3)?,
            body: row.get(4)?,
        };
        children.entry(post.parent_id).or_default().push(post);
    }
    serde_json::to_writer(out, &build(&children, 0))?;
    Ok(())
}

这样一段再普通不过的"取行、映射成结构体"的代码，数据要经过下面这些步骤，才能变成你手里的 Post：

 数据库文件
     │
     │  默认：read() 把整页拷进 SQLite 的 page cache    [拷贝]
     │  - 开启 mmap_size：直接读映射进来的文件页
     ▼
 B 树页（page cache 或文件映射）
     │
     │  sqlite3_step → OP_Column 从记录中解出 user / body
     │    - 在页内：拷进寄存器缓冲区                    [拷贝]
     │    - 跨溢出页：malloc 缓冲区，逐页拼接            [分配][拷贝]
     │  有 ORDER BY / GROUP BY 时：写进 sorter 再读出    [拷贝]
     ▼
 寄存器缓冲区
     │
     │  sqlite3_column_text → rusqlite row.get()
     │  指针只活到下一次 next，Post 只能拥有一份拷贝
     │  user / body 各自变成 String                     [分配][拷贝] × 2
     ▼
 Post { user: String, body: String, .. }
     │
     │  按 parent_id 建树，递归写出
     │  serde_json::to_writer 写出 JSON
     ▼
 JSON

在这样的过程里，SQLite 和它的 API 约定都要求字符串换一个地方存放。字段越多、字符串越长、查询越复杂，这条路上的拷贝和分配就越多。这其实也是常见数据库的标准做法：自己管理 buffer pool，在用户态掌控内存，不让操作系统决定哪些页留在内存里。代价是 pool 里的页随时可能被替换，数据要交出去，就必须先拷贝一份。如果像 DBOS [1] 设想的那样，把数据库放进操作系统的内核，由它来管理操作系统的状态，用户态的 buffer pool 和内核的页缓存或许就不必再分成两层。

可是在常见的 Web 应用里，很多查询的主要工作其实只是数据的加工和传递：从 SQL 里取出数据，经过一些简单的处理转换成对应的结构体（Java 里的 POJO），再序列化成 JSON，通过 HTTP 返回。GraphQL [2] 把这件事做成了接口规范：调用方描述想要的字段和嵌套结构，服务端照着这个形状把数据库里的列取出来、组装好、序列化出去，几乎不做别的。这类几乎纯读取和重排的工作，在 Web 后端里占的比例越来越大。

在这样的情况下，Post 的每个 String 字段都要分配一次，字段越多，分配越多。再回头看刚才的流程图，你会发现字符串一共被拷贝了两次：第一次是 SQLite 在 step 取列时，把它从页里拷进寄存器缓冲区（即使启用了 mmap，这一次拷贝也省不掉）；第二次是映射成 Post 时，又从寄存器缓冲区拷进各个字段。但 row.get_ref 明明能直接借出 &str，让 Post 的字段借用它，不就省掉第二次拷贝了吗？遗憾的是，row 只活到下一次 next，借用它的 Post 带不出这一行，编译器会直接拒绝。而建树要等所有行到齐，SQL 的排序和 JSON 函数都给不出深度不定的嵌套结构，这些行必须同时拿在手里。这次拷贝来自 SQLite API 的约定，靠上层的写法很难绕开。

实现从存储到返回的零拷贝计算

MMAP Storage

Andy Pavlo 说过，MMAP 会毁掉你的数据库和你的生活 [3]。这是他和 Crotty、Leis 那篇 CIDR 2022 论文被否掉的候选标题之一，最后定名为 Are You Sure You Want to Use MMAP in Your Database Management System?。论文列举了在数据库里用 mmap 替代 buffer pool 的四类问题：事务安全、IO 停顿、错误处理、性能。正如标题所说，这里并没有直接调用 mmap 自己实现存储，而是用 LMDB 作为存储后端。LMDB 是一个成熟的嵌入式 KV 存储引擎，它的设计规避了论文里最致命的事务安全问题 [4]：

• 默认只读映射。 文件以只读方式映射，进程不能通过指针修改它。宿主程序的野指针写不坏数据库，映射里也不存在会被内核擅自写回磁盘的脏页；试图修改只读事务返回的值，会直接触发 SIGSEGV。
• 写入不经过映射。 写事务要修改的页先在堆内存里改好，提交时用 pwrite 写回文件，再按配置 fsync。什么时候落盘、按什么顺序落盘，由 LMDB 自己决定。
• 写时复制的 B+ 树（影子分页）。 已提交的页从不原地修改：改一个叶子，就写一份新页，并沿路径一直复制到根。
• 两个元数据页交替使用。 提交的最后一步是写元数据页，记下新的根。两份交替写，崩溃后总有一份是完整的，数据库不会停在写了一半的状态。
• 读者表保护快照。 每个只读事务都登记自己看到的版本，它可能读到的旧页不会被回收复用。所以只读事务读到的值，在事务结束前一直有效、地址不变，这正是 零拷贝 SQL 计算 所依赖的保证。
• 单写者。 同一时刻只有一个写事务，论文也提到 LMDB 正是靠这一点避免了事务之间的冲突。

当然，论文里的另一些问题 LMDB 并没有解决：缺页时线程会同步阻塞，IO 错误会变成 SIGBUS，哪些页留在内存由内核决定。LMDB 的前提是热数据放得进内存，而在 SQLite 所面向的嵌入式场景里，这个前提通常是成立的。

Data Encode

在 KV 存储之上实现 SQL，第一步是决定一行数据怎么变成 key 和 value。TiDB 的做法很有代表性 [5]：

行：  t{TableID}_r{RowID}                       →  [col1, col2, col3, ...]
索引：t{TableID}_i{IndexID}_{索引列的值}_{RowID}  →  null

同一张表的行共享同一个前缀，按主键排好序，全表扫描和索引查询都变成了一段连续 key 的范围扫描。这里的实现也是同样的结构：key 是"表 ID + 类型标记 + 主键"，value 是这一行的各列。

对零拷贝来说，关键在 value 里字符串怎么存。以后面测试里用到的 orders 表为例，插入 (1, 7, 'paid', 42, 'hello') 这一行，它的 value 是这样的：

  00                               空值位图
  01 00 00 00                      id = 1
  07 00 00 00                      customer_id = 7
  04 00 00 00 70 61 69 64          status：长度 4 + "paid"
  2a 00 00 00                      amount = 42
  05 00 00 00 68 65 6c 6c 6f       note：长度 5 + "hello"
  00 00 00 00 00 00 00 00          语句戳：写入这一行的语句编号，更新时用来跳过本语句刚写入的行

字符串以"长度 + 原始字节"的形式连续存放。解码 note 时只要读出 4 字节的长度，就得到一段指向 LMDB 页的（指针，长度），正好就是一个 &str，不需要任何转换。LMDB 又保证大值所在的溢出页是连续的，所以无论字符串多长，这段字节在映射里都是连续的一整块，可以直接借出去。注意一行的所有列是一个 LMDB value：LMDB 把放不进叶子的 value 分配在一段连续的溢出页上，所以不只是某个字段连续，而是整行连续，status 和 note 只是同一段字节里的两个偏移。

把大值放到单独的页上，和 PostgreSQL 的 TOAST、InnoDB 的外部页是同一个思路，解决的是行膨胀，让只读小列的查询不用碰大值。但这些机制不解决拷贝：值取回应用时照样要拷。真正不拷的做法是像 FILESTREAM 那样把值变成文件句柄交出去，可那样它就不再是 SQL 值了，引擎里不能再对它过滤、排序、求长度，和行的事务快照也对不齐。这里的区别在于，溢出页仍然在同一个映射、同一个只读事务里，算子和调用方拿到的是同一段字节。

Execution

字符串能从存储里借出来，只是第一步。一条 SQL 要经过扫描、过滤、排序、分组、join 等一连串算子，才会把结果交给调用方，其中任何一层把字符串拷贝一份，零拷贝就在那里断掉。这是一种风格：存储给出一个生命周期，算子不打断它，Rust 的借用检查让这件事能在编译期得到保证。

值的表示：要么拥有，要么借用。 字符串和二进制值都用同一个类型表示（简化后）：

pub struct MaybeMapped<B: ?Sized>(Repr<B>);

enum Repr<B: ?Sized> {
    Owned(B::Owned),     // 自己拥有的内存：SQL 里的字面量、表达式算出来的新值
    Mapped { ptr, len }, // 一对（指针，长度），指向只读事务读到的页
}

两种状态会出现在同一条查询里。比如 where note = 'hello'，常量 'hello' 是 Owned，列值 note 是 Mapped。

至于列值什么时候是 Mapped，取决于事务。只读事务开始时声明"读到的字节在事务结束前一直有效、地址不变"，行解码就直接产出 Mapped；写事务无法保证这一点，解码时只能拷贝，产出 Owned。

物化算子只拷贝指针。 物化算子必然要收集上游算子的行：排序要攒齐所有行，分组要保存分组键，hash join 要建哈希表，窗口函数要留住整个分区。它们保存值时，Mapped 字符串只拷贝（指针，长度），不拷贝内容。整条查询都在同一个只读事务里，这些页不会失效，所以只要没有触发 spill，物化算子就能在内存容器里以借用的方式保存值。只有少数情况会产生新的字符串：表达式算出来的值（比如 upper(note)），以及数据量大到需要 spill 时，序列化写出再读回来的值。理论上 spill 出去的文件也可以用 mmap 读回并继续借用，但这是一项额外的做法。

借用的期限：对外靠编译器，对内靠约定。 借用的风险在于指针活得比页久，这里分两层处理：

• 交给调用方的结果，与事务的生命周期绑定。结论里的 Post 就是这样：它可以活过某一行，一直用到事务结束，但想把它带出事务，编译器会直接拒绝。
• 执行器内部的借用靠约定。同一条预编译的语句可以在不同事务里反复执行，所以每次执行开始前，算子都要清空上一次留下的借用值。这一层编译器检查不到，由 debug 构建下的存活检查兜底：读到已结束事务的借用值会直接 panic。

Benchmarking SQL Execution: SQLite with mmap vs. LMDB SQL

下面的测试里，两边装载完全相同的数据、建同样的索引、执行同样的 SQL：语句只准备一次，所有执行都在同一个只读事务里完成。SQLite 开启了 PRAGMA mmap_size（1 GiB，大于数据库文件，整个文件都被映射），所以两边都通过内存映射读数据库文件，IO 这一层的条件是相同的。

• LMDB SQL：跑在 LMDB 只读事务上的 SQL 引擎，字符串从存储一路借用到调用方。
• LMDB SQL（强制拷贝）：同一条查询放进写事务执行，字符串会被拷贝，用作对照组。
• SQLite：SQLite 3.45.1，开启 mmap。

分配量在 libc 的 malloc 处统计。测试机为 i9-13900HX，程序绑定在同一个 P 核（cpu8）上运行。

测试的目的不是证明哪边更快，而是找出拷贝的成本从什么长度开始显现。所以字符串长度从 64 B 一直拉到 256 KiB：64 B 是 SQLite 领先的一档，256 KiB 则远超一般业务表里一列的大小，中间几档才是常见的文档、日志和 JSON 字段。

表 1 到表 3 使用下面的 orders 表。note 的长度从 64 B 到 256 KiB 分档装载，每档单独建库；每次查询按 (customer_id, status) 命中约 10 行。

create table orders (
    id          int primary key,
    customer_id int,
    status      varchar,  -- 'new' / 'paid' / 'shipped' / 'done' / 'void'
    amount      int,
    note        varchar
);
create index orders_customer_status on orders (customer_id, status);

表 1：普通索引查询

按索引取出约 10 行，调用方读取每个字符串。复现：examples/alloc_trace.rs [6]。

select id, status, amount, note from orders
where customer_id = $1 and status = $2 and amount > $3;

单位：每格为"p50 耗时 µs / 每次执行分配 KiB"。

表 2：长度函数

查询条件和数据与表 1 相同，只把投影换成长度函数。第一列是取出 note 后由调用方对字符串取 len()；char_length 在 SQLite 里对应 length()。

单位：每格为"LMDB SQL / SQLite 的 p50 耗时 µs"。

表 3：多重物化算子下的数据分配与计算性能

读取与表 1 相同的行，但让字符串先后经过分组、窗口函数和排序三个物化算子。复现：examples/alloc_trace.rs 中的 multi-op 变体 [6]。

select status, note, peak, max(peak) over (partition by status)
from (select status, note, max(amount) as peak from orders
      where customer_id = $1 and status = $2 and amount > $3
      group by status, note) t
order by note desc;

单位：每格为"p50 耗时 µs / 每次执行分配 KiB"。

表 4：100 篇 JSON / CSV 文档的解析

每次按 grp 取出 100 篇文档，把结果保留到查询结束之后，再解析成结构体。LMDB SQL 的结构体字段直接借用事务里的文本；SQLite 按常见写法，每个字段一个 String。CSV 场景用结构相同的 csv_docs 表，body 存一行 CSV。复现：examples/borrowed_parse.rs [7]。

create table json_docs (
    id   int primary key,
    grp  int,      -- 每组 100 篇
    body varchar
);
create index json_docs_grp on json_docs (grp);

select id, body from json_docs where grp = $1;

单位：每格为"p50 耗时 µs / 每次执行分配 KiB"，每次执行取 100 行。

表格分析

LMDB SQL 的分配量和数据大小无关，SQLite 的分配量跟着返回的数据走。 表 1 里 LMDB SQL 始终是 0.4 KiB；SQLite 从 4 KiB 起每行分配一次，总量约等于返回的字节数。SQLite 在 64 B 和 1 KiB 时显示 0，不表示没有拷贝：短字符串被拷进了一块复用的缓冲区，所以统计不到分配。检查返回的指针可以看到，LMDB SQL 的指针全部落在数据库文件的映射里，SQLite 的一个都没有。

SQLite 在短数据上很快，但耗时随数据长度增长；LMDB SQL 的耗时和长度无关。 64 B 时 SQLite 只要 2.99 µs，比 LMDB SQL 还快，拷贝几十个字节的代价可以忽略。随着 note 变长，SQLite 的耗时和分配量一起增长，到 256 KiB 时是 66.14 µs，拷贝成了主要开销。LMDB SQL 的耗时始终在 2.4 到 4.4 µs 之间，它不读字符串的内容，自然也不受长度影响。

差距来自拷贝，不来自 IO。 让 LMDB SQL 强制拷贝字符串后，它的耗时和分配都和 SQLite 落在同一个量级（256 KiB 时 61.6 µs 对 66.1 µs）。

octet_length 两边都是常数时间，不能作为零拷贝的论据。 LMDB SQL 对借用的 &str 取 len()；SQLite 对只作为长度函数参数的列，直接从记录头读长度，不加载内容、不读溢出页（OP_Column 的 OPFLAG_BYTELENARG），所以反而更快。

char_length 两边都要扫完全部字节，64 KiB 以上 LMDB SQL 快 6 到 7 倍。 LMDB SQL 直接在映射的页上计数（chars().count()，256 KiB 档约 28 GB/s）；SQLite 先把溢出页的内容拼进 malloc 的缓冲区，再逐字符计数。这是"读完全部内容、处理很轻"的典型情形：计算本身便宜，拷贝占了大头，零拷贝的收益最明显。如果写入时记下字符数或"是否纯 ASCII"，char_length 也能做到常数时间，目前没有实现。

每经过一个物化算子，差距就放大一次。 表 3 里 64 KiB 和 256 KiB 两档，SQLite 的分配量是返回数据的 13 到 17 倍，因为每个算子都要把记录写进去再读出来；LMDB SQL 只分配哈希表和排序数组用的约 4 KiB。LMDB SQL 的耗时仍然随 note 增长，原因是分组要对整条 note 求哈希。

解析本身两边一样快。 16 KiB 解析 JSON 时，扣掉取数据的耗时，纯解析两边差不多（159 µs 对 155 µs）。LMDB SQL 快出的部分，几乎全来自取数据时没有拷贝。

结论

回到一开始的代码案例中，在同样功能的代码下可以写成这样：

use kite_sql::db::{Transaction, TxnResultIter};
use kite_sql::storage::lmdb::LmdbStorage;
use kite_sql::Model;
use serde::Serialize;
use std::borrow::Cow;
use std::collections::HashMap;
use std::error::Error;
use std::io::Write;

#[derive(Default, Model, Serialize)]
#[model(table = "posts")]
struct Post<'a> {
    #[model(primary_key)]
    id: i32,
    thread_id: i32,
    parent_id: i32, // 0 表示顶层评论
    user: Cow<'a, str>,
    body: Cow<'a, str>,
}

#[derive(Serialize)]
struct Comment<'a> {
    #[serde(flatten)]
    post: &'a Post<'a>,
    replies: Vec<Comment<'a>>,
}

fn build<'a>(children: &'a HashMap<i32, Vec<Post<'a>>>, parent: i32) -> Vec<Comment<'a>> {
    let Some(posts) = children.get(&parent) else { return Vec::new() };
    posts.iter()
        .map(|post| Comment { post, replies: build(children, post.id) })
        .collect()
}

fn write_thread(tx: &mut Transaction<'_, LmdbStorage>, thread_id: i32, out: impl Write) -> Result<(), Box<dyn Error>> {
    // Post 借用 LMDB 的页，活到事务结束，所以可以先全部收齐再建树
    let mut children: HashMap<i32, Vec<Post>> = HashMap::new();
    let posts = tx
        .bind(|ctx| {
            ctx.from::<Post>()?
                .filter(|e| e.column(Post::thread_id())?.eq(thread_id))?
                .finish()
        })?
        // 每个字符串字段都是 Cow::Borrowed，直接指向 LMDB 的页
        .txn_orm::<Post>();
    for post in posts {
        let post = post?;
        children.entry(post.parent_id).or_default().push(post);
    }
    serde_json::to_writer(out, &build(&children, 0))?;
    Ok(())
}

同样的过程，换到这里是这样的：

 数据库文件（LMDB 映射）
     │
     │  只读事务：页在事务结束前一直有效、地址不变
     ▼
 B+ 树页 / 溢出页（大值在映射里是连续的一整块）
     │
     │  行解码：读出 4 字节长度，得到（指针，长度）
     ▼
 Cow::Borrowed(&str)，直接指向页
     │
     │  txn_orm：放进 Post 的字段
     ▼
 Post { user: Cow::Borrowed, body: Cow::Borrowed, .. }（活到事务结束）
     │
     │  按 parent_id 建树：只移动指针
     │  serde_json::to_writer 写出 JSON
     ▼
 JSON

两段代码除了类型，几乎一模一样：逐行读出 Post，按 parent_id 放进 HashMap，最后递归建树并序列化。不同的是，这里的 map 里只有指针：Post 的字符串字段是 Cow<'_, str>，在只读事务里都是 Cow::Borrowed，直接指向 LMDB 的页。它们的生命周期绑在事务上而不是某一行上，所以第一行的 Post 可以和最后一行的一起留在 map 里等着建树，直到写出 JSON 为止，字符串一次都没有被拷贝。字段用 Cow 而不是 &str，是因为在写事务里页可能被改动，那时字段会退化成 Cow::Owned 的拷贝。rusqlite 那边不是不能借用，row.get_ref 就能借出 &str，但它只活到下一次 next；建树要等所有行到齐，借用 row 的 Post 活不过下一次 next，所以放进 map 的只能是拷贝。

这个优势有自己的适用范围。短行、逐行处理的负载两边差不多，SQLite 还略快；写事务里字符串照样要拷贝；TPC-C 这类负载看不出变化。聚合算子把借用的行留在手里，对应的页就要留在内存里，但这些页是 SQLite 读同样数据时也要进页缓存的干净文件页，内核可以随时回收；回收不掉的堆内存反而是零拷贝这边更少（表 3）。借用的结果活多久，只读事务就要开多久，而 LMDB 的旧页在有读者引用时不能回收，长时间持有结果又伴随大量写入，数据库文件会膨胀。

感谢阅读。文中的实现和测试代码都在 KiteSQL 仓库里：https://github.com/KipData/KiteSQL。

参考

[1] Athinagoras Skiadopoulos, Qian Li, Peter Kraft, Kostis Kaffes, Daniel Hong, Shana Mathew, David Bestor, Michael Cafarella, Vijay Gadepally, Goetz Graefe, Jeremy Kepner, Christos Kozyrakis, Tim Kraska, Michael Stonebraker, Lalith Suresh, Matei Zaharia. DBOS: A DBMS-oriented Operating System. PVLDB, 15(1): 21–30, 2022. doi:10.14778/3485450.3485454. PDF: https://www.vldb.org/pvldb/vol15/p21-skiadopoulos.pdf

[2] GraphQL Specification, September 2025 Edition. GraphQL Foundation. https://spec.graphql.org/September2025/. 项目主页：https://graphql.org/

[3] Andrew Crotty, Viktor Leis, Andrew Pavlo. Are You Sure You Want to Use MMAP in Your Database Management System? CIDR 2022. 项目页：https://db.cs.cmu.edu/mmap-cidr2022/. PDF: https://db.cs.cmu.edu/papers/2022/cidr2022-p13-crotty.pdf。候选标题见 Andy Pavlo 的讲座录像 https://www.youtube.com/watch?v=1BRGU_AS25c 00:52 处。

[4] LMDB API 文档，Symas Corporation：http://www.lmdb.tech/doc/group__mdb.html。MDB_val 一节说明返回的值"valid only until a subsequent update operation, or the end of the transaction"，并且"commonly point into the database itself"；MDB_WRITEMAP 一节说明默认的只读映射能防止野指针写坏数据库。

[5] PingCAP. TiDB Computing，"Mapping table data to Key-Value" 一节：https://docs.pingcap.com/tidb/stable/tidb-computing/

[6] examples/alloc_trace.rs：https://github.com/KipData/KiteSQL/blob/main/examples/alloc_trace.rs。运行：cargo run --release --example alloc_trace --features lmdb,orm

[7] examples/borrowed_parse.rs：https://github.com/KipData/KiteSQL/blob/main/examples/borrowed_parse.rs。运行：cargo run --release --example borrowed_parse --features lmdb,orm

这是 Redox OS 2026 年 11 月 8 日的一篇开发记录，作者是 MJ Pooladkhay。记录写 Virtio-FS 驱动，以及 Redox 作为客户机跑在 Cloud Hypervisor 上。Reddit 转发帖作者是 ribbon_45，采集时 23 分、2 条评论。帖子时间是 2026-11-08 15:54 UTC。

Virtio-FS 驱动已经合进 base 仓库的 drivers/storage/virtio-fsd。让 Redox 在 Cloud Hypervisor 上启动到 shell 的内核、bootloader 和驱动改动也已经合入。文章写了两个方向。客户机方向是这篇的主体：Redox 跑在 Cloud Hypervisor 里，去掉以前在 QEMU 上用的老 PC 硬件依赖。宿主方向还是提案。客户机这部分由 NGI Zero Commons 和 NLnet 的 Virtualized Redox 资助。

Virtio-FS 让虚拟机使用宿主机上的目录。Redox 的 virtio-fsd 用 FUSE 协议，经 virtqueue 和宿主机上的 virtiofsd 通信。每个共享目录是一个 scheme，路径是 /scheme/virtio-fs.<tag>，tag 来自宿主机。驱动在 QEMU 和 Cloud Hypervisor 上都能用，带自测。目录项缓存用 LRU，不用的项通过 FUSE_FORGET 告诉宿主忘掉。

启动到 shell 时记下的问题和对应合并请求：

• bootloader!61：传给 ExitBootServices 的 memory-map key 过期，bootloader 出不了 UEFI。
• base!422：virtio-blk 被识别成 transitional VirtIO 设备。Cloud Hypervisor 只提供 modern 设备，根磁盘没有出现。
• kernel!762：登录提示出现了，键盘输入进不去。串口输出是轮询的，输入走中断，中断指向不存在的 8259。legacy 中断改走 I/O APIC。
• 没有 PIT，也没有 HPET，定时等待不会醒来。

文章里的 ping 记录是 ping -c 4 1.1.1.1。第一包大约 15.304 ms 有回复，后面三包没有发出去。第一包是马上发的。后面的包要 time scheme 在 1 秒后唤醒。内核里 timeout::trigger 原来只由 PIT 中断处理函数调用。QEMU 上 HPET 走同一条中断线。Cloud Hypervisor 没有 PIT，也没有 HPET，这个处理函数不跑。读时钟仍然有效，kvmclock 会把 TSC 换成纳秒，所以第一包的往返时间是正常的。时钟中断没有在跑。调度器的抢占 tick 也停了，系统变成协作式调度。

kernel!762 的修复是：没有 HPET 时，每个 x86 CPU 用自己的 local APIC timer，模式是 TSC-deadline。tick 周期用 kvmclock 已有的比例，从纳秒换成 TSC tick。处理函数补上原来 PIT 处理函数的工作，投递到期的 timeout，并驱动调度器 tick。修完以后四包都发出去，间隔 1 秒，抢占调度恢复。

文章写，现在还不能当可部署实例。Cloud Hypervisor 上 Redox 还不能自己关机。重启已经可以，走键盘控制器的 reset 线。后面的工作包括兼容 cloud-init 的首次启动配置、PVH 直接启动、virtio-vsock、virtio-balloon、virtio-rng，以及快照恢复。现有 VirtIO 设备是 virtio-blk、virtio-net、virtio-fs、virtio-gpu。Redox 还不做 PVH，仍然走 UEFI。Firecracker 没有 UEFI，PVH 做完才开这条路。

SweetEbb9819 的评论有 2 分，写用 stub Linux VM 做硬件驱动值得注意。phip1611 的评论有 1 分，写看到更多人用 Cloud Hypervisor。

原文链接：https://www.redox-os.org/news/virtualized-redox/

Actix Web 这个季度发了 100 多个 crate

这是 Actix Web 维护者 robjtede 发在 r/rust 的一份季度报告。采集时 21 分、1 条评论。帖子时间是 2026-11-08 23:51 UTC。actix-web 仓库采集时 24934 星、1994 个 fork，许可证 Apache-2.0。

报告写，这个周期 Actix 生态有 100 多次 crate 发布。HTTP QUERY 方法进了路由宏、手工路由和 awc 客户端。宏路由用 #[query]，手工路由用 web::query()。h2c 和 TCP no-delay 改成默认开启。报告写，某些负载的内存占用最多大约少 99%。中间件可以用 Error::add_response_mapper() 改错误响应。CORS 中间件已经用它修一个旧 bug。静态文件 Files::new() 可以有多个根目录。Files::try_compressed() 可以发预先压缩好的资源。

安全修复写在报告里，也能对上 GitHub release。解压后的请求体受已配置的大小限制。大窗口 Brotli 解压关掉。畸形的 chunked 结束符会被拒绝。静态文件服务修了用户可控文件名带来的 stored XSS，以及 Windows 隐藏文件保护绕过。报告写，自动解压这套隐式行为会在 v5 去掉。报告建议执行 cargo update -p=actix-web。

GitHub 上能对上的发布包括这些。actix-web 4.18.2 发布于 2026-11-06，默认 form payload 上限提到 32 KiB。form、JSON、bytes、string extractor 的解压后大小受同一套限制，公告编号 GHSA-qph8-7859-gq2f。actix-http 3.20.3 关掉大窗口 Brotli，公告编号 GHSA-7p9w-p5qm-5gc5。actix-http 3.20.2 拒绝把单独的 LF 当作 chunked 最后结束符，公告编号 GHSA-2q7f-mf9f-5qhr。actix-http 3.21.0 发布于 2026-11-08，默认打开 TCP_NODELAY。这条 release 写，HTTP/1.x 内存使用有明显改进。actix-http 3.20.5 在优雅关闭时向 HTTP/2 连接发 GOAWAY，在途 stream 结束后关掉连接。actix-multipart 0.8.7 给 MultipartFormConfig::max_parts() 加了默认上限 100。actix-router 0.5.5 的 MSRV 是 1.89，路径参数可以抽成 Vec 或 tuple。

DavidXkL 的评论有 2 分，写自己主要用 Actix Web，会去看这些改动。

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

cel-rust 上线浏览器 playground

cel-rust 是用 Rust 写的 Common Expression Language 解释器。CEL 是一门非图灵完备的表达式语言，语法接近 C。仓库在 https://github.com/cel-rust/cel-rust 。采集时 713 星、84 个 fork，许可证 MIT，最近推送是 2026-11-08。crates.io 上的包名是 cel，当前版本 0.15.0，发布于 2026-10-06，累计下载 5719704，近期下载 4915558，18 个版本。这篇帖子写的是 playground。0.15.0 没有随这篇帖子更新。

作者 alexsnaps 2026 年 11 月 8 日 12:25 UTC 在 r/rust 发帖。采集时 18 分、5 条评论。帖子写，cel-rust 几年前加了 Wasm 支持，这次把 playground 放到浏览器里，地址是 https://cel-rust.github.io/playground 。页面上可以开关自动运行。关掉时，Ctrl+Enter 或 Run 才会求值。表达式、输入和输出可以开语法高亮。高级模式在表达式旁边放 AST 浏览器。主题有 System、Light、Dark。代码主题列出 GitHub、Catppuccin、Solarized、Dracula、Tokyo Night Moon。设置和上次写的内容留在这个浏览器里。

README 的安装方式是 cargo add cel。示例编译 add(2, 3) == 5，用 Env::stdlib() 和 Context::with_env，再 context.add_function 注册 add。

Shnatsel 的评论有 15 分，问 CEL 是什么。IvanIsCoding 的评论有 8 分，写 CEL 非图灵完备，语法像 C。评论里的例子以 request.method in ['GET', 'HEAD'] && request.path.startsWith('/api 开头，采集时后面被截断。syncerr 的评论写，自己用 CEL 做 protobuf 消息校验，并提到 protovalidate 和 protobuf-es。

原文链接：https://cel-rust.github.io/playground

原生 Mac GUI 工具包问要不要只做 AppKit

这是 layla4you2 发在 r/rust 的一篇提问。作者在做一套面向 Mac 的 Rust GUI 工具包。帖子里没有放仓库链接。采集时 0 分、16 条评论。帖子时间是 2026-11-09 01:36 UTC。

作者列出现有选择。webview 用 Tauri。自绘 UI 用 egui、Iced、Slint。另一种是 SwiftUI 前端加 Rust FFI。作者写，文本框行为、VoiceOver 和大表格是这些方案里经常对不上 Mac 应用习惯的地方。

作者写，这套工具包里每个 view 是真正的 AppKit 控件。表格用 NSTableView。作者写，一百万行滚动没有问题，因为 AppKit 只取可见行。状态放在 signal 里。改一个 signal 只更新受影响的控件，不重建 view tree。菜单、工具栏、文档、undo、拖放和 Dark Mode 走系统。还有一个 self-check 模式，会驱动应用并检查屏幕上的内容。

podule-games 的评论有 4 分，写只做 Mac 会是阻碍，因为这样就在和 Swift 竞争。rjzak 的评论有 2 分，写自己从 Slint 换到 egui，只做 Mac 的工具包可以接受，需要菜单栏支持。作者回复有 1 分，写菜单栏已经覆盖，包括应用自己的菜单和菜单栏右侧图标。Shoddy-Childhood-511 的评论有 1 分，写对只做 Mac 的 GUI 工具包没有兴趣。

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

From Rust中文社区 Mike

社区学习交流平台订阅：

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

装到磁盘上的东西差得更多：rpi 的 Windows 发布包 14.35 MiB，claude 一个可执行文件 231 MB，codex 284 MiB，opencode 172 MiB，Pi 是 384.9 MiB 的包外加 91.2 MiB 的 Node。

最慢和最快差 78 倍，最大和最小差 27 倍。这不是谁调优得更好一点，是构造不同：rpi 是一个不带运行时的 Rust 二进制，另外几个要么自带 Node/Bun 运行时，要么拖着上百兆的依赖树。

先看表，再说条件

条件：同一台机器（Windows 11，Ryzen 9 7950X，32 逻辑处理器），每个工具跑 15 次取中位数。rpi 和 Pi 都用离线开关并指向独立的空配置目录，避免加载本机插件。claude、codex、opencode 按安装后的默认行为跑，它们没有对应的离线开关。体积是发布包或已安装可执行文件的实际大小；rpi 那一栏是 zip 发布包，解压出的二进制会比它大一些。

图 1 和图 2 把同一张表画成条形。看启动那张时注意 node 那一根：单是启动运行时就要 19.4 ms，任何 Node 系工具都不可能比它更快。看体积那张时注意 Pi 的两段颜色，工具本体之外还要单算一份 Node 运行时。

--version 只测进程创建到打印版本，不含任何模型请求。它衡量的正是你每次敲命令、每次被编辑器拉起都要付的那笔启动成本。我这 15 次落在 10.4 ms 到 17.3 ms 之间，你重跑很可能得到 12–13 ms，属同一量级。同一台机器上单独跑 node --version 就要 19.4 ms，这是任何 Node 系工具起跑线的地板。

需要说清一处：启动这一项 rpi 是五个里最快的，但比 claude 只快 6 ms，差距远没有体积那么大。真正拉开数量级的是体积（14 MiB 对 231–385 MB）和内存，下一节说内存。

内存：地板 12 MiB，空闲 1 MB 出头

官方离线基准里，rpi 空配置刚就绪的常驻内存是 12.0 MiB，同机对照的 Pi 是 91.5 MiB，冷启动快 10.7 倍（Windows 11、release、离线、每次用新的空配置目录，基准版本 rpi 0.3.6 / pi 0.87.1）。

我自己这台机器上的快照是另一个尺度。31 个 rpi.exe 里，11 个闲置会话的驻留内存只有 1.12 MB 到 1.67 MB，加起来 16.2 MB。10 个正在跑会话的进程在 33.28 MB 到 111.91 MB 之间，中位 48.3 MB。4 个给编辑器用的宿主进程中位 87.1 MB。

图 3 是同一批进程的对照：14 个会话进程挂在同一个父进程下，闲下来的 11 个驻留贴到 1 MB 线，还在干活的 3 个是 45.67 MB、118.99 MB 和 143.07 MB。同一份程序，差别只在有没有活在跑。会话状态逐帧写进 JSONL，进程安静时没有请求在跑，驻留页就能被系统换出去。

12 MiB 和 48 MB 并不矛盾：前者是空配置刚能应答的地板，后者是带着扩展、跑过多轮工具调用、留着会话历史的真实工作进程。地板决定你能不能把它塞进小机器，后者决定你干活时要付多少。

这三个数字能换来什么

容器和 CI 里不用再铺运行时

一个 14 MiB 的二进制丢进镜像就能跑，不用为了一个 Agent 在镜像里装一层 Node 和一份 node_modules。空配置就绪 12 MiB，512 MB 的容器留得下。

多开会话不心疼

一个会话一个进程，闲下来驻留掉到 1 MB 级，11 个这样的实例加起来 16.2 MB；关掉一个立刻还回去。按我这台机器的中位数估，10 个活跃会话加 4 个宿主约 830 MB，剩下的就是闲置的那几个，它们几乎不占物理内存。

每次调用 11 毫秒

编辑器每拉起一次、脚本里每循环一次、CI 每个 job 都要启动一次。按一天 300 次算，rpi 是 3.3 秒，Pi 是 45.4 秒。次数越多，这个差距越明显，而且它不需要你改任何配置。

为什么能这么小

一是没有运行时。Rust 直接编成机器码，不需要 Node 或 Bun 陪着一起启动，那 19.4 ms 的地板和 91.2 MiB 的运行时都不存在。

二是不带依赖树。扩展是独立的 cdylib，用到才加载；Pi 那种 384.9 MiB 的目录，是把它所有可能用到的依赖都先装到磁盘上。

三是会话不常驻内存。会话状态逐帧写进 JSONL 文件，进程闲下来时可以被系统换出，这就是那 11 个 1 MB 会话的来历。它的代价写在后面。

自己验一遍

rpi 发布的是单个二进制，v0.21.1 的 Windows 包 14.35 MiB、macOS arm64 包 13.40 MiB、Linux gnu 包 14.70 MiB（GitHub release 元数据，2026-11-07），不需要 Node 运行时：

cargo install rpi-cli
rpi --version

不想装 Rust 工具链就用预编译安装脚本：

curl -fsSL https://raw.githubusercontent.com/bigfish1913/pi-rust/main/scripts/install.sh | sh

装好后你可以照着上面的表自己量一遍：

# 启动：连跑 15 次取中位
$t = 1..15 | ForEach-Object {
  $sw = [Diagnostics.Stopwatch]::StartNew()
  & rpi --version | Out-Null
  $sw.Stop(); $sw.Elapsed.TotalMilliseconds
}
($t | Sort-Object)[7]

# 内存：开几个会话后看驻留与提交
Get-Process | Where-Object { $_.ProcessName -eq 'rpi' } |
  Select-Object Id,
    @{n='WS_MB'; e={[math]::Round($_.WorkingSet64/1MB, 1)}},
    @{n='Priv_MB'; e={[math]::Round($_.PrivateMemorySize64/1MB, 1)}} |
  Sort-Object WS_MB -Descending

11 毫秒、14 MiB、12 MiB 就绪、1 MB 空闲：四个数字都在上面，也都能在你自己的机器上重跑一遍。

• 官网：https://rpi.bigfisharc.cn/
• 文档：https://rpi.bigfisharc.cn/docs.html
• 仓库：https://github.com/bigfish1913/pi-rust

纯 Rust 写的嵌入式多模态数据库，面向具身智能（机器人、AR、边缘设备）：向量（DiskANN）、全文（BM25+jieba）、时序、空间四类索引 + 列存 + ACID + SQL，单进程嵌入式零依赖，MIT 协议。cargo add motedb / pip install motedb-python / npm install motedb 即用。

• GitHub: https://github.com/motedb/motedb （0.18 全家福: https://github.com/motedb/motedb/releases/tag/v0.18.0 ）
• 文档: https://motedb.github.io · 10 分钟可跑的 demo notebook 在仓库 examples/motedb-demo.ipynb

-- 0.18 新语法一览
CREATE CONTINUOUS VIEW sensor_1m AS
  SELECT TIME_BUCKET('1m', ts) AS minute, device,
         AVG(v) AS v_avg, FIRST(v, ts) AS v_open, LAST(v, ts) AS v_close
  FROM sensor GROUP BY minute, device;   -- 查询时惰性刷新，当普通表用

ALTER TABLE frames DROP COLUMN legacy;   -- 逻辑删除，schema 演进
ALTER TABLE frames RENAME COLUMN v TO voltage;

Rust 侧新增 Database::open_shared_readonly：一个写者 + N 个读者进程同时挂活动目录（flock SH/EX），只读会话零字节落盘（目录字节指纹验收）。

v0.18 的主线：把一笔技术债连本带利还掉

v0.17 五轮猎虫收尾时留下一个实证结论：四轮"同一谓词不同路径不同结果"类缺陷全部同根——SQL 比较语义存在于 11 个互不相识的实现里。0.18 工作流 A 就是还这笔债，做法值得写三段。

1. 先写特征测试，再动实现（PR-1）

新建 semantics.rs 作为唯一语义层：Cmp3 三值 + OrdOp + coerce_pair（Cow 零分配归一：Bool↔数值、方括号向量文本）。动代码之前先写 38 行类型对 × 8 算子的矩阵测试 + 把引擎各路径的 NULL/Kleene 现状用 12 个探针锁定——先证明"现状是什么"，再谈"改成什么"。

2. 差分测试是照妖镜（PR-4）

同一份随机谓词，九条执行路径对拍（SELECT / DELETE / UPDATE / JOIN 两种写法 / 子查询 IN / 聚合 / GROUP BY+HAVING）。上线第一天就揪出 7 个预先存在的跨路径分歧，全是 0.17 就在的：

• NOT (flag IN (0,1)) 在某条路径放行全部行——In 分支用了裸 ==，NULL 成员匹配了 NULL 值；
• UPDATE 探针第一版用 a = a + 1000 探测，忘了 NULL + 1000 = NULL——行原样留下，差分器把它当分歧报出来，测试工具自己的 bug 也被差分抓了；
• 最有意思的裁决：a NOT IN (0, '7') 里哈希归一把纯数字文本 '7' 当微秒时间戳解析（时间戳解析器 first-try 连带），与相等路线分歧。裁决是纯数字文本不再按时间戳归一——推翻了自己 PR-1 里锁定的怪癖。特征测试不是圣旨，差分对拍才是。

3. CI 棘轮：只降不升（PR-5）

src/sql 里裸值比较点从 49 处收编到清单化，门禁脚本数违规、上限写在单独文件里（当前 50），只许降不许升，行内注释可豁免。从此"再往执行器里手写一个 =="过不了 CI。

产品侧补的四个硬伤

• B1 多进程共享只读: 写者持 EX 时读者明确报错; 脏目录（WAL 非空/未干净关闭）拒绝打开——只读者永不修复，修复是写者的职责。零落盘用目录字节级指纹验收。
• B2 Schema 演进: DROP COLUMN 是逻辑删除——列段按位置存列，物理宽度绝不能收窄（dropped 槽位写 NULL 占位），bincode 位置敏感所以目录镜像链 modern→V017→V013 保跨版本兼容。
• B3 向量召回硬化: 先造测量工具（对抗数据 p50/worst 如实基线），发现真病灶是"列段写缓冲新行对索引路径不可见"——补合并层 + 新鲜度护栏（未入图占比超阈值降级暴力扫并后台重建）。诚实声明：对抗簇数据 p50 0.85-1.0 是真实水平，不藏。
• B5 连续视图: 惰性全量重算 v1，语义如实声明。开发日志里最连续的踩坑是：把视图物化结果注册进 CTE map 后，连环揪出三个预存在的 CTE bug——WITH x AS (...) SELECT COUNT(*) FROM x 之类形态此前会硬报 Table not found。新特性的测试强度反过来给老特性抓了虫。

发布工程

全量门禁 4300+ 测试从 ~2.5h 提到 ~30min（独立 release-test profile 关 LTO——300+ 测试二进制的链接时间才是大头）; EXPLAIN 改为决策点实录（thread-local trace 重放执行，计划永不与实际漂移）; 文档版本单源 + CI 校验（README 曾三处三个版本号）; Release 页由 tag 自动生成; 发版前发现 cargo package 会把未跟踪的本地文件收进包——exclude 补 .zcode/ 后 package --list 核验归零。

给同行的三个小教训

1. 差分对拍 > 特征测试。特征测试锁现状，差分测试找真相——两者冲突时（纯数字文本时间戳）信差分。
2. 新功能是老代码的压力测试。连续视图把 CTE map 用满，三个陈年 bug 当场现形。给新功能写测试时，顺手把相邻老路径也拍一遍。
3. 位置敏感的序列化（bincode）加字段 = 全部旧目录损坏。用镜像链在解码边界转换，别在结构体上加带默认值的尾部字段赌运气。

链接

• GitHub: https://github.com/motedb/motedb （good first issue 已挂 10 条，欢迎首贡献）
• Release Notes: https://github.com/motedb/motedb/releases/tag/v0.18.2
• 文档: https://motedb.github.io · 能力清单（每行对应实现与测试）: 仓库 CAPABILITIES.md

这是 Thessi4Coil 发在 r/rust 的一篇故障记录。记录里的导出命令报告成功，留下的 CSV 文件是空的。采集时 0 分、10 条评论。帖子时间是 2026-11-07 17:20 UTC。

导出路径上的写入都用了 write_all(...)?。作者写，没有忽略 Result，也没有 unwrap。导出内容小，能放进 BufWriter<File> 的缓冲区。每次 write_all 返回 Ok(())，字节还在内存里。函数末尾返回 Ok(())。之后 writer 被 drop。

std::io::BufWriter 的文档写，drop 之前必须调用 flush。drop 会尝试把缓冲区写出去，这个过程里的错误会被忽略。调用 flush 可以先把缓冲区清空，drop 时就不再做文件操作。文档写默认缓冲区容量目前是 8 KiB，以后可能变。作者写，当时文件系统已满，真正的写入失败发生在函数已经返回成功之后。

作者给出的复现用 Linux 的 /dev/full。打开它并包进 BufWriter，写入短字符串，write_all 返回 Ok(())。显式调用 flush() 得到 ENOSPC。

作者写，当场的修改是在返回成功前加上 flush()?。导出路径改成先写临时文件，写完再 rename，避免失败的导出替换掉原来有效的文件。作者写，flush() 和 sync_all() 是两件事，这次失败停在字节还没有写到文件上。

thegentlecat 的评论有 31 分，把帖子的写法标成 “It wasn’t X, it was Y” speedrun。complexicat 的评论有 24 分，内容是 “slop”。EpochVanquisher 的评论有 5 分，写文件的最后一次使用应该是 flush、sync 或 close，按需要选一个。Kenzzer 的评论有 3 分，写这是常见的 I/O 问题，记得 flush 缓冲区。

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

RAVET 0.1.0 一次导出五种插件格式

RAVET 是用 Rust 写音频插件和独立音频程序的框架，全称 Rust Audio Visual Engineering Toolkit。c0wcud 2026 年 11 月 7 日在 r/rust 发了 0.1.0。采集时 0 分、2 条评论。仓库在 https://github.com/mo0kid/ravet 。采集时仓库 1 星、0 个 fork、121 个提交，许可证 GPL-3.0。GitHub release 写，标签 v0.1.0 发布于 2026-11-05。仓库写还没有 crates.io 包，使用方式是依赖这个 tag。最低 Rust 版本是 1.88。

0.1.0 的发布说明写，产品描述写一次，里面有 processor、参数、保存的状态和编辑器，RAVET 再构建各个格式。README 写，0.1.0 把一份产品描述导出成 CLAP、VST3、AUv2、AAX 和 LV2，平台是 macOS、Windows 和 Linux。作者帖子里的格式名单是 VST3、CLAP、LV2、Audio Unit 和 AAX。

发布说明写，Web 编辑器在 macOS、Windows、Linux 上可用，覆盖该平台上支持编辑器的格式。MIDI 输入和输出在每个格式里可用。插件可以告诉宿主延迟变化，并在格式支持时报告 tail。自动化可以按采样应用，也可以每个 block 一次。Bypass 可以由 processor 处理，也可以由 RAVET 处理，方式包括硬切换、交叉淡化和冻结直通。每个格式都处理 denormal。DSP 部分列出立体声 FIR 滤波器和立体声 oversampler。

作者帖子写，支持路径上的音频线程不分配、不加锁、不阻塞。核心音频、事件和参数 crate 用 no_std，没有分配器。参数有永久 key，调整顺序后宿主 ID 保持稳定。保存的状态带版本和迁移钩子。编辑器是嵌在宿主窗口里的 web view，使用 WebKit、WebView2、WebKitGTK，通过一个小的 JS API 和插件通信。

最小例子是 tempo-synced delay。作者写 DSP 大约 350 行普通 Rust，插件描述不到 80 行，目录是 examples/delay-plugin。更大的例子是 DW-303，一个开源的 TB-303 风格合成器和音序器，仓库在 https://github.com/mo0kid/DW-303 。

发布说明记下的测试机是这些。macOS Apple silicon 上，delay 例子跑过 REAPER 的 CLAP、LV2、AU，Ableton Live 12 的 VST3，Logic Pro 的 AU，Pro Tools 的 AAX。Linux 和 Windows 11 上跑过 REAPER 的 CLAP、VST3、LV2，带编辑器。macOS Intel、Rosetta 下跑过 REAPER 的 CLAP、VST3、LV2、AU。Windows 上的 AAX 能构建并通过检查，还没有在 Windows 版 Pro Tools 里跑过。独立音频和 MIDI 通过 DW-303 在三个平台上跑过。

发布说明写了限制。导出层构建的插件处理 32-bit float，一条主总线。Pro Tools 里，编辑器中输入的值在点到别处时才应用。Windows 编辑器还没有跟随显示缩放。作者写，闭源产品另有商业许可，年收入 5 万美元以下免费。README 写，最终商业协议还没定，README 本身不授予商业许可。

complexicat 的评论有 4 分，写这条帖子违反 rule 7。作者回复有 -1 分，写发帖前读过 rule 7，插件已经在 REAPER、Live、Logic 和 Pro Tools 里跑过。

原文链接：https://github.com/mo0kid/ravet/releases/tag/v0.1.0

编译到 Rust 的语言问能不能用 crates.io

这是 ElephantElectrical31 发在 r/rust 的一篇提问。作者在做一门编译到 Rust 的新语言，想把包发到 crates.io，名字用 {语言名}_*。包里同时放原始源码和生成出来的 Rust 文件。作者问这样是否可以，还是应该自建 registry。作者写，Rust 用户也可以直接用这些库。采集时 2 分、29 条评论。帖子时间是 2026-11-07 14:38 UTC。

FantaSeahorse 的评论有 71 分。评论写这些包里的文件不算 Rust 源文件，建议给它们单独建公开仓库。

Clean_Assistance9398 的评论有 9 分，问既然编译目标是 Rust，为什么不直接写 Rust，以及这门语言相对 Rust 要解决什么问题。

lenscas 的评论有 3 分，写一门语言可以把 Rust 当作多个输出目标之一。评论提到有人做过 Rust 到 C，C 作为编译目标比较乱。评论把 Rust 写成更适合 native 生态的目标，Web 再用 JS。

stinkytoe42 的评论有 13 分，建议把包系统做成能识别 Git，引用指向公开 Git 服务器。短名字如 语言名/包名 可以自动指向 GitHub 或一个可配置前缀，完整的 https:// 和 ssh:// 链接也可以用。同一作者另一条 8 分的评论写，crates.io 有这套做法没有的问题，其中一条是命名空间。评论写，语言成熟后再做完整的包系统，起步阶段不依赖正式包管理。

lahwran_ 的评论有 -1 分，写 Git 引用有一批问题，crates.io 的设计就是用来处理这些问题的。

ryo33h 的评论有 5 分，写自己的语言主后端也是 Rust，正在做自己的包管理器。列出的考虑点有中心化还是分布式、semver 还是 rev hash、是否支持最小发布时间。同一作者另一条 1 分的评论介绍 Totebag。Totebag 是一个实验性包管理器，用这门语言自己写。它用 Git，不用 registry，依赖按内容哈希锁定。信任是分布式的，用户可以选择信任谁，以及一个 commit 被观察到之后等多久。

AnArmoredPony 的评论有 2 分，内容是 “yeah we do that”。

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

Dave Abrahams 在 IWACO 讲可变值语义

这是 Dave Abrahams 发到 r/rust 的一场演讲视频。演讲标题是 Safe Systems Programming with Mutable Value Semantics，场合是 IWACO 2026 的 keynote。YouTube 频道是 Hylo，时长 1:03:43。dabrahams 2026 年 11 月 8 日 00:08 UTC 发帖，采集时 13 分、3 条评论。帖子正文写，这场演讲讲的是 Hylo 语言，上个月在 IWACO 做的，里面有关于 Rust 的内容。

YouTube 简介写，Hylo 是一门建立在严格可变值语义上的语言，英文是 strict mutable value semantics，缩写 MVS。简介写，MVS 给安全、易用和效率留出空间，并限制这几项之间的冲突。Hylo 的设计尽量用上这个重合点。演讲解释 value semantics 指什么、为什么重要，以及 Hylo 怎样在不引入引用类型的情况下支持 MVS。

teerre 的评论有 2 分，写搜索作者名字时看到退休信息，这次看到作者还在做演讲。dabrahams 的回复有 2 分，写自己大体上已经离开，并附了 #humanityftw。BoringAccount-_- 的评论有 1 分，写看完了这场大约一小时的视频。

原文链接：https://www.youtube.com/watch?v=op51SyyPJmw

From Rust中文社区 Mike

社区学习交流平台订阅：

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

整目录删除当然最快，代价是最终产物也会一起消失。只想清掉缓存，又得挨个项目判断哪些目录能删。这个两难，是我写 cargoc 的原因。

cargoc 把 Cargo 的中间构建文件放到专用目录，按工作区记录和清理空闲缓存；最终产物仍留在 Cargo 原来的 target-dir。它解决的是“哪些中间文件可以清、什么时候清”。文件是否变小，取决于后续有没有删除空闲缓存；编译仍由 Cargo 完成。

target 里到底该删什么

Cargo 现在可以把两类产物分开：target-dir 保存面向使用者的最终产物，build-dir 保存构建过程中的中间文件。两者默认仍可能落在工作区的 target 目录里，所以日常使用时看起来像一整块缓存。

这一区分很重要。最终程序、库或安装结果通常需要继续使用；中间文件则可以在合适的时候重新生成。直接运行 cargo clean 会交给 Cargo 自己处理清理范围，不能把它当成“只删除中间文件”的命令。

Cargo 1.91 的构建缓存文档说明了这两个目录的关系：https://doc.rust-lang.org/1.91.0/cargo/reference/build-cache.html。

cargoc 的做法是：为每个受管理的工作区分配一个专用的 build-dir，让真实 Cargo 继续完成编译。target-dir 的既有配置不变，清理器也不连接最终产物目录。

目录关系示意，不是磁盘占用实测。图中省略了命令接管、异常和进程管理分支。交互版及源码定位：https://assets.bigfisharc.cn/images/cargoc-social/layout-zh-ff0d1a14e5.html。

缓存根目录下，每个工作区使用自己的路径哈希目录。统一管理不等于让多个项目共用一份可写缓存，也不等于跨项目依赖去重。安装 cargoc 后，旧 target 里的文件也不会自动搬走；旧目录没有立刻变小是正常的。

正在编译的缓存，不能只按时间删除

“很久没修改”只能帮助排序，不能证明目录现在没人使用。一个构建可能已经启动，只是还没有产生新的文件。

一次受管理构建里有三层保护：

• 当前工作区持有租约，自动清理会显式保护它；
• 清理候选时，还要取得候选工作区的租约和扫描到的 Cargo 原生锁；
• 包装器停止构建时，只关闭本次调用拥有的进程组或 Windows Job，不按进程名杀掉机器上的其他 Cargo。

因此，清理器遇到锁忙的缓存会跳过。它宁愿暂时达不到空间目标，也不会为了凑数字强删正在使用的目录。

构建退出时，顺序也不能反过来：包装器先关闭自己的进程树，再更新最后使用时间并释放租约，最后才执行结束后的清理。这样清理器不会在子进程仍可能访问缓存时，把它当成空闲目录。

代码路径也对应这三个职责。runner::run 定位工作区、注入 build-dir 并管理一次 Cargo 调用。Store::lease 和 Store::collect 负责缓存身份、租约与候选清理。OwnedChild 负责本次进程组或 Windows Job 的生命周期。

源码中的 构建生命周期 和 候选缓存清理 可以对照阅读。链接固定到当前项目提交，避免以后文件变化后读者找不到对应位置。

预算是软限制，不是硬配额

cargoc 的默认配置给受管理的中间缓存设置了 80 GiB 软预算。超过预算，或者缓存所在卷的剩余空间低于期望值时，自动清理会从较久没有通过 cargoc 使用的工作区开始处理。默认超过 7 天未使用的缓存，也可能因过期被清理。

压力清理的低水位比例默认是 0.8，所以容量目标可以按配置推算为：

80 GiB × 0.8 = 64 GiB

64 GiB 是清理策略的目标，不是“已经释放了 16 GiB”。清理按整个工作区的候选缓存进行，也不会精准停在这个数字。活跃缓存受保护、候选缓存不足，或缓存卷与最终产物不在同一块盘时，结果都可能不同。

默认还要求缓存卷保留 20 GiB 空间；运行期间低于 1 GiB 紧急阈值时，cargoc 会停止本次调用拥有的 Cargo 进程树。这两项检查只保护缓存卷和当前调用，不是整台机器的硬盘配额。最终产物、Cargo 下载的依赖数据、旧 target 和其他软件的占用，都不计入这 80 GiB。

先用显式命令试一遍

当前仓库源码版本是 0.1.4。预编译包和安装方式以项目的 Releases 页面及 README 为准：https://github.com/bigfish1913/cargoc/releases。

受管理构建需要 Cargo 1.91+。项目声明的 Rust 1.88 是编译 cargoc 自身的最低版本，不能拿来判断被包装的 Cargo 是否支持 build-dir。

安装后可以先检查版本并初始化 cargoc 自己的配置：

cargo --version
cargoc --version
cargoc init

init 默认创建 $CARGO_HOME/cargoc.toml；没有设置 CARGO_HOME 时，通常是 ~/.cargo/cargoc.toml。它与 Cargo 的 config.toml 分开，不会把构建目录配置写进 Cargo 的全局配置。

如果指定缓存位置，要使用新的专用目录：

cargoc init --cache-dir /path/to/cargoc-cache

不要把已有的非空目录、源码、笔记或最终产物目录直接指定为缓存根。程序会拒绝接管没有所有权标记的非空目录。

进入一个 Rust 工作区后，先从显式调用开始：

cargoc build
cargoc status
cargoc clean --dry-run

status 用来确认受管理目录、逻辑占用和缓存卷剩余空间。clean --dry-run 只报告空闲受管理缓存的拟删除结果。removed_bytes 是预演数字，不是已经回收的磁盘空间。确认范围后，再决定是否执行 cargoc clean。

空间不足时，先看阈值和缓存卷

一次实际演示中，Windows 上的缓存卷空闲空间低于默认的 20 GiB，cargoc 没有启动 Cargo，而是返回：

cargoc: Insufficient free disk after safe cleanup; refusing to start Cargo

这类提示先用 cargoc status 和 cargoc config 检查缓存位置、空闲空间和阈值。可以释放空间，或把专用缓存放到更充足的卷；不要为了让命令继续就直接降低日常保护值。

现有演示使用 Cargo 1.99.1、本地 cargoc 0.1.2 和独立配置。演示配置把 min_free_gib 临时调为 2，并保留紧急阈值 1，离线构建才成功。下面的图是实际输出的排版摘录，不是终端窗口截图，也不用于证明空间收益。

图中条件是 Windows / Cargo 1.99.1 / cargoc 0.1.2；[demo config] 表示独立配置。removed_bytes 是预演的拟删除量，不代表本次已经释放的空间。

想继续输入 cargo，可以另外启用接管

只安装 cargoc 不会改变普通 cargo 命令。希望继续输入 cargo build、cargo test 时，可以启用它提供的 PATH 入口接管：

cargoc setup --enable
export PATH="$HOME/.cargoc/bin:$PATH"
command -v cargo
cargo --version
cargoc setup --status

Unix 下 setup 不会替你修改 shell 启动文件。需要把 export 放进对应的 shell 配置。Windows 会写入用户级 PATH；启用后要重新打开终端，再用 Get-Command cargo 检查入口。

这个入口是用户目录中的 shim/代理，不替换 Rustup 的真实 Cargo。代理会转发参数和退出码。IDE 或脚本如果写死真实 Cargo 的绝对路径，或者使用 rustup run <toolchain> cargo ...，仍可能绕过接管。

不想继续接管时，执行：

cargoc setup --disable

它只移除 cargoc 自己的入口，不删除 Rustup 的 Cargo，也不会自动删除已经生成的受管理缓存。

cargoc clean 和 cargo clean 不是一回事

cargoc clean 清理的是空闲的受管理中间缓存，而且即使没有设置自动清理，也会处理这批缓存。最终产物在它的删除范围之外。

如果执行：

cargoc exec clean

这条命令会转发给 Cargo 原生的 clean，可能删除 Cargo 目标目录中的最终产物。exec 只是解决命令名冲突，不是关闭缓存管理的开关。

同样，非托管的旧 target 或旧版 build-dir 不会被 cargoc 自动接管。需要清理它们时，先停止相关构建和 IDE，再确认原来的 target-dir、最终产物和恢复副本。之后由原所有者单独处理。cargoc 提供的 audit 只读盘点旧目录，不会替你删除。

它适合解决哪一种问题

如果你只是偶尔清理一个 Rust 项目，手动处理可能已经够用。cargoc 适合的是多个工作区长期积累中间构建文件，希望把这批可重建数据集中到一个有归属、可观察、可预演的缓存根里。

它不会带来跨项目依赖复用，也不承诺编译速度提升。空间回收来自删除空闲中间缓存，代价是之后可能重编。它也不负责最终产物、Cargo 下载缓存或整台机器的磁盘配额。

项目地址：https://github.com/bigfish1913/cargoc。反馈时请带上操作系统、Cargo/cargoc 版本、调用方式，以及脱敏后的配置和错误输出；这些信息有助于区分目录、版本和入口接管问题。

原文链接：https://blog.bigfisharc.cn/blog/rust-disk-cargoc/

Servo 0.7.0 是 Servo 浏览器引擎的一个版本，官方博客写它包含 2026 年 9 月合入的全部改动，一共 527 个提交。博客发布日期是 2026-11-05。HimikoTogaFromUSSR 2026 年 11 月 6 日把 Phoronix 的报道发到 r/rust，采集时 187 分、18 条评论。GitHub release 写，v0.7.0 已经就绪，内容是 9 月的改动。crates.io 上的 servo crate 版本是 0.7.0，最低 Rust 版本 1.88.0，许可证 MPL-2.0。

新合入的网页平台功能包括 :checked 伪类、user-select、<progress>、CSS typed arithmetic、alpha() 和 font-width。DOM 侧有 Selection 的 getComposedRanges() 和 direction，CSS modules 和 text modules，Canvas 的 roundRect()，VTTCue 的 getCueAsHTML()，以及 WebCrypto 的 MLKEM768-X25519。开发者工具控制台会提前求值 JS 输入。安全更新把 SpiderMonkey 升到 v153.3，mozangle 升到 v0.7，两边都带了上游报过的安全修复。

兼容性例子写了两条。egui.rs 的 demo 在 --pref dom._webegpu_enabled 下按预期工作。一个 Candy Crush 游戏现在可以玩。Control+A，macOS 上是 Command+A，会选中文档里的全部内容。密码输入框里的文本不能再被复制。

嵌入 API 有几处调整。无障碍工具产生的事件走 Servo::forward_accessibility_action。WebView::clear_session_history 可以清掉会话历史。WebView::set_throttled 被去掉，WebView 隐藏时自动节流，显示时停止。webgl 进入 default_web_features，不想带 WebGL 的嵌入方需要关掉默认 feature。多进程模式在构建时打开，博客写去掉这项支持大约少 2MB。Linux 上打开了线程亲和性提升。Android 的 JVM 兼容目标升到 11。Windows 主机可以交叉编译 OpenHarmony 构建。OpenHarmony SDK 更新到 API 23。

release 附件里的 servo-aarch64-linux-ohos.hap 签给 OpenHarmony，不是 HarmonyOS。HarmonyOS 目前需要自行签名，说明指向 ArkTS Servo Demo 仓库。

捐款数字写在文末。经常性捐款是每月 8144 美元，比 8 月高 1%。thanks.dev 上有 37 个依赖 Servo 的 GitHub 用户在赞助，比 8 月多 1 个。博客列出 10 位这个月第一次给 Servo 合入补丁的贡献者。

Bassfaceapollo 的评论有 58 分，希望 Servo 至少成为 Gecko 的替代。noobjaish 的评论有 19 分，提到 Ladybird 计划在接下来几个月放出二进制。r2vcap 的评论有 0 分，写 Servo 由 Linux Foundation Europe 支持，并提到华为通过 OpenHarmony 参与。barsoap 的评论有 2 分，问这怎么构成对中国的依赖，并写 545400 欧元的资助相对很小。

原文链接：https://servo.org/blog/2026/11/05/september-in-servo/

tokio-tun 0.23.0 补上 Linux offload

tokio-tun 是用 Tokio 异步创建 TUN/TAP 设备的 Rust 库。仓库在 https://github.com/yaa110/tokio-tun 。n47id 2026 年 11 月 7 日发到 r/rust，采集时 0 分、0 条评论。采集时仓库 95 星、35 个 fork、58 个 tag。最新版本是 v0.23.0。

README 写，支持的平台上，包 I/O 都通过 AsyncFd 注册到 Tokio。没有单独的轮询循环，没有阻塞回退，也不自己抽出文件描述符。Tun::builder() 可以设名字、地址、前缀、对端和 up。名字留空时由内核分配。一次 recv 返回一个 IP 包。写回 TUN 的数据必须是合法的 IPv4 或 IPv6 包。

v0.23.0 的 Linux 部分加了 virtio-net offload。TunBuilder::offload() 打开 TSO/GSO/GRO。新增 VirtioNetHeader、VIRTIO_NET_HDR_LEN 和 GSO 常量。每个收到的包前面有 10 字节的 virtio_net_hdr，发出去的包也要带这个头。offload() 配置 checksum、TSO4、TSO6 和基于 NAPI 的 GRO，并且不能和 packet_info() 一起用。NAPI GRO 作用在从用户态写进内核的包上，不会合并交给用户态的包。打开 offload 后，接收缓冲区至少要 VIRTIO_NET_HDR_LEN + 65_536 字节，因为 GSO 包可以超过接口 MTU。多队列附加时，每个队列都要调用 .offload()，状态不一致会被拒绝。

FreeBSD 这一版补了 TAP 的 MAC 地址，TunBuilder::persist()，以及 TAP 的 broadcast。persistence 保留接口身份。FreeBSD 在最后一个描述符关闭时会清掉地址和 up 状态。分配改用 SIOCIFCREATE2，避免误接管或拆掉已经存在的 persistent 或改过名的设备。

平台表写的是：Linux 有 TUN、TAP、多队列和 offload。macOS 只有 TUN，走 utun。Android 和 iOS 只有 TunQueue，分别接 VpnService 和 NetworkExtension 的 fd。FreeBSD 有 TUN 和 TAP，没有多队列，也没有 offload。macOS 和 FreeBSD 上，TUN 的 IPv6 destination 需要 /128 前缀。

原文链接：https://github.com/yaa110/tokio-tun

业余开发者问能不能给 rustc 提补丁

这是 Motor_Alternative944 发在 r/rust 的一篇提问。作者写自己没有计算机专业背景，最近在自学计算机科学和编译器，想知道学习期间能不能给 rustc 或类似的编译器项目做贡献，以及维护者会不会因为水平不够而不收。采集时 22 分、30 条评论。帖子时间是 2026-11-06 15:32 UTC。

Ok-Zookeepergame4391 的评论有 38 分，写除了能力以外没有门槛。Crouton4035 的评论有 67 分，写理论上谁都可以提议代码，实际要有专业水平的知识和经验，补丁才比较有机会通过。评论还写，维护者普遍报酬低、已经超负荷，不确定自己在做什么的时候不要增加他们的工作量。评论建议先把 Rust 代码库下载下来读，先不要指望马上贡献。

Anthony356 的评论有 1 分。作者写自己是业余开发者，大约 4 年前开始学，大约一年半前给 rustc 提了自己最早的一批 PR 之一，最近加入了编译器团队。评论写，业余作者如果愿意听审阅意见，维护者一般不介意一份出于好意的 PR。评论把自己被邀请进编译器团队的原因写成：有时间去处理大家都认为状态不好、但因为复杂而没人愿意碰的部分，并把它记下来。评论写，审阅者到目前为止比较友好，不熟悉的 git 命令也可以问。建议是不要为了改而改。

Kivooeo1 的评论有 12 分，写自己有一篇讲这个话题的文章，以及两篇从 issue 到合并的后续，里面有审阅过程。评论写可以帮忙看，前提是自己做，不要让 LLM 把整个 PR 做完再一直点继续。评论写，维护者现在要花很多时间和精力处理这类自动提交。Equivalent_Head_4803 的评论有 6 分，写 issue 经常在自己动手之前就被机器人占掉，维护者的时间被指向 GitHub 的自动提交占掉了。

QuasiRandomName 的评论有 11 分，写自己最早的开源贡献是给 rust-lang 的两个小 PR，和 fmt::UpperHex / LowerHex 里的检查有关。Eh2406 的评论有 5 分，写时间够的话，靠持续做会变成熟悉这块的人。在那之前，碰到不懂的缩写或术语就去查。查得到就学会了。解释难找，可以建议把链接补上，并记下自己找过但没有答案的地方。找不到解释，就告诉维护者。MilkEnvironmental106 的评论有 7 分，建议从 GitHub 上相对简单的 issue 开始提 PR。

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

目录扫描先看 ignore，再谈 Rayon

这是 weaztoven 发在 r/rust 的一篇提问。作者在写一个 Rust CLI，扫描目录并对文件做清理。现在是单线程，准备用 Rayon 把遍历和处理并行起来。问题是普通 SSD 和网络挂载上，线程池打满时有什么坑，Rayon 是不是还合适，有没有限制并发的写法。采集时 10 分、8 条评论。帖子时间是 2026-11-06 16:49 UTC。

tylerlarson 的评论有 23 分。评论写，Rayon 更偏 CPU 并行。只做目录遍历时，评论把 BurntSushi 为 ripgrep 写的 ignore crate 称为现成做法。它自带多线程池，并行遍历，自动遵守 .gitignore，并处理线程边界。作者回复会去看，因为手写 gitignore 规则比较麻烦。

layla4you2 的评论有 3 分。评论写，Rayon 的池子是每个核一个线程，适合 CPU 工作。文件 I/O 大部分时间在等。本地 SSD 用默认值可以。网络挂载上每次 stat 或 unlink 都是一次往返，在途请求要比核数多，但不能把服务器打满。并发数做成 -j 参数，不要猜。遍历可以用 ignore 的 WalkParallel，也就是 ripgrep 用的那条，或者 jwalk。限制并发的写法是：walker 进一个有界的 crossbeam channel，再由 N 个工作线程消费，背压由 channel 给出。清理时先删子项再删目录，不要跟随符号链接，把 NotFound 当成正常情况。

The_8472 的评论有 1 分，建议先用 strace 看实际系统调用和时间花在哪里。如果要 stat 几百万个文件，可以考虑用 io_uring 把这些调用收成一次系统调用。fiedzia 的评论有 1 分，写瓶颈多半在操作系统或硬件，除非先证明不是这样。

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

From Rust中文社区 Mike

社区学习交流平台订阅：

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

lean-miri 是把 Rust 的 Miri 解释器移植到 Lean 4 的项目，用来在 Miri 的执行模型下证明一段 Rust 程序没有未定义行为。项目页在 https://proofs-rs.github.io/lean-miri/ ，仓库在 https://github.com/proofs-rs/lean-miri 。作者 ___yuni 2026 年 11 月 5 日发到 r/rust，采集时 150 分、26 条评论。

Miri 检查的是具体执行。lean-miri 把同一套操作语义放进 Lean 4，于是可以写成定理：对满足前提的输入，解释器的结果不是未定义行为。作者写，Miri 已经覆盖高级 trait 和裸指针，也实现了现有已知的各类未定义行为检查。移植这条现成的解释器，就不另做一套只覆盖语言子集的语义。

目前移植了解释器的大部分。已经证明没有未定义行为的例子有两个。一个是空函数 empty_function。空函数仍会初始化调用帧再返回。定理覆盖调用初始化和这次调用里每个有限执行前缀，前提是声明过的调用方和执行配置。安全的资源耗尽被允许，不保证每种资源供给都能正常返回。另一个是 duplicate_prefix：把缓冲区前 n 个字节复制到后面 n 个字节。n == 0 直接返回 true。n > buf.len() / 2 返回 false。通过检查之后，用 as_mut_ptr 取出指针，在 unsafe 里调用 std::ptr::copy_nonoverlapping。引用按 Tree Borrows 处理。站点写，对声明域里的每个 count 和每份输入，定理给出正常返回、没有解释器错误，以及任何被允许的有限前缀上都没有未定义行为。它不保证每一种 Rust 调用历史都能形成这次调用，也不额外保证返回的布尔值。

程序进入 Lean 的路径是：Rust 写的 exporter 把 MIR 和元数据编成 JSON，Lean 写的解释器读这份 JSON。元数据包括相关标准库类型的布局和大小。作者在评论里写，exporter 处于信任边界，另外有一批差分测试，这不等于移植 100% 忠实。编译器、exporter，以及解释器和 Rust 的对应关系，站点都列为信任边界。

验证 Tree Borrows 的状态转移时，作者碰到 Miri 内部断言失败，报给了 rust-lang/miri#5543。issue 标题是 [tree borrows] Internal assertion failure during wildcard access traversal。

限制也写在说明里。Lean 里的解释器还没有做性能优化。duplicate_prefix 的证明检查要超过 2 小时。导出的程序数据大约 500MiB。现在是向前执行的步进解释器，没有最弱前置条件这类程序逻辑，中间引理要手写。为了先把验证跑通，当前实验关掉了垃圾回收和数据竞争检测。第二个例子的证明超过 70 万行 Lean。作者写，移植大部分由 agent 完成，中间有不少人工介入；例子程序的验证需要更多人工指导。作者写自己的背景是计算机科学和逻辑，技术决定是自己做的。

JoJoModding 的评论有 36 分，问程序怎么进 Lean、怎么知道移植忠实、Tree Borrows 的 bug 是什么。annodomini 的评论有 29 分，问有多少是 LLM 写的，以及作者本人有没有形式化验证经验。

原文链接：https://proofs-rs.github.io/lean-miri/

不用 String::new 造出字符串

这是 Matthias Endler 写的一篇说明，列了不用 String::new 得到 String 的若干写法。页面写最后更新于 2026 年 11 月 5 日。作者从 RustLab 2026 回来后把一场没有录像的闪电演讲写成了文章。mre__ 同日发到 r/rust，采集时 94 分、14 条评论。

字符数组可以 into_iter().collect()。UTF-8 字节可以 String::from_utf8(vec![102, 101, 114, 114, 105, 115])，这六个字节是 ferris。给单元变体 ferris 派生 Debug，再 format!("{:?}", Mascot::ferris)，得到的也是这个名字。作者写，Debug 输出不是稳定的序列化格式，这里只是这个名字碰巧能用。

CString::new("ferris").unwrap().into_string().unwrap() 会先加上 NUL，转回 String 时去掉终止符并检查剩余字节是合法 UTF-8。另一条路是故意把带 NUL 的字节交给 CString::new，用 unwrap_err().into_vec() 拿回被拒绝的字节，再 pop() 掉注入的 NUL。char::from(u8) 把每个字节当成码点，不按 UTF-8 解码。收成 String 时再编码成合法 UTF-8。原字节如果是多字节 UTF-8，结果文本可以是错的，但转换本身不会失败。

include_str!("file.rs").to_owned() 在编译期嵌入文件文本。文件内容是 ferris，没有尾随换行。扩展名不影响，宏不把文件当 Rust 解析。

线程名那条：thread::Builder::new().name("ferris".to_owned())，再在子线程里读 current().name()。子进程那条：同一个可执行文件带 --child 时 print!("ferris")，父进程用 Command 取 stdout，再 String::from_utf8。

浮点那条用 f64::from_bits(0x0000_7369_7272_6566)。这组位按小端字节读是 f e r r i s 加两个 0。to_le_bytes() 后再丢掉两个填充字节。String::from_raw_parts 那条先 Box::new(*b"ferris")，Box::into_raw 交出分配，再以指针、长度 6、容量 6 组装。type_name::<ferris>() 取类型名的最后一段，再 parse::<String>()。作者写，type_name 没有稳定的命名约定。

panic 那条用 panic_any(format!("ferris"))，catch_unwind 之后 downcast::<String>()。这依赖 unwind。panic = "abort" 时进程会直接退出。

格式化填充那条用空字符串和填充说明符：format!("{0:f>1}{0:e>1}{0:r>2}{0:i>1}{0:s>1}", "")。> 右对齐，前面的字符是填充，数字是最小宽度。r>2 用同一个空参数填出两个 r。

somebodddy 的评论有 23 分，指出线程那条里 "ferris".to_owned() 已经造出了 String。作者回复同意。SuplenC 的评论有 7 分，写自己在 RustLab 现场看了这场演讲。

原文链接：https://endler.dev/2026/wrong-ways-to-create-strings/

compile_fail 抓住了多出来的 Display

这是 TroutWindlass 发在 r/rust 的一篇工作记录。作者维护一个内部 crate，给几个服务处理凭据。采集时 47 分、9 条评论。帖子时间是 2026-11-05 21:18 UTC。

crate 里有 Secret<T>。它故意不实现 Display。值可以传递，需要时显式取出。Debug 给出打码后的表示。format!("{}", secret) 不能把原始秘密写进日志。

作者先前加了一个 compile_fail doctest，要求用 Display 格式化 Secret 时编译失败。上周有人整理格式化代码，加了一个泛型 Display 实现。普通单元测试通过了。这个 doctest 失败了，因为那段代码现在能编译。编译器按新的实现接受了 API 原本要拒绝的写法。

作者写，compile_fail 不完美。片段可以因为无关原因编译失败。他们把否定测试和正例配在一起，也在看更精确的 UI 测试。作者写，加一个 trait 实现通常是把 API 变宽。这次它去掉了设计里的一条限制。

Tomato7550 的评论有 40 分，建议直接实现一个写出 [redacted] 的 Display，再断言这个行为。WormRabbit 的评论有 6 分，提到 static_assertions::assert_not_impl_any!。

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

指针来源记录所属分配

这是一篇对照 Rust 和 C++ 指针来源（provenance）的说明。作者 Sofiabelen15 2026 年 11 月 5 日发到 r/rust，采集时 41 分、4 条评论。

来源记录的是指针属于哪一次分配、因此可以碰到哪块内存。它是编译器里的抽象，不作为字段跟地址存在一起。CHERI 是例外。文章用一段 C++ 说明这件事：opaque 只有前向声明，f 里 int x = 1，调用 opaque(p) 后 return x。Clang -O2 把它收成直接返回 1。编译器认为 p 不能等于 &x，因为 p 不是从 x 派生出来的。LLVM IR 里，%2 是 x 的分配根。根不同，经 %0 写入就不会改 %2。

把 &x 转成 uintptr_t 再传出去，地址就被暴露。编译器必须假设别人能从整数把指针造回来，于是放弃这个优化。

Rust 的 ptr::addr 读出地址数字，并声明不会把它铸回有效指针，因此不暴露来源。作者用对应实验看生成的代码，opaque(p) 之后仍有 mov eax, dword ptr [rsp + 12]，也就是重新加载 x。这一步优化目前同样被放弃。

带标志位的指针用 with_addr 保留来源、只换地址：let tagged: *const u32 = p.with_addr(p.addr() | 1)，清掉最低位再用 with_addr 恢复。p.addr() | 1 对 u32 未对齐，tagged 不能解引用，解引用是未定义行为。旧写法 p as usize 再铸回 *const u32 能跑，但 Miri 会警告 integer-to-pointer cast，并指向 ptr::with_exposed_provenance。警告写，这种语义下 Miri 可能漏掉指针错误。严格来源 API 对应 MIRIFLAGS=-Zmiri-strict-provenance。p as usize 会暴露 p 的来源；重建的指针如果还落在同一次分配上，来源可以恢复。落到另一次分配上，来源就丢了。

Shnatsel 的评论有 34 分，附上了 Ralf Jung 关于指针和来源的几篇文章。

原文链接：https://sofiabelen.github.io/projects/pointer-provenance-in-rust-vs-cpp/

From Rust中文社区 Mike

社区学习交流平台订阅：

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

一个 227 万条化合物指纹的 HNSW 索引，召回率不对。不是低，是低得反常：

Recall@10 ≈ 0.88
Recall@50 ≈ 0.85 ← k 越大，找回来的反而越少

在健康的 HNSW 上，固定 efSearch 时 Recall@k 应随 k 增大走平甚至逼近 1。倒挂意味着"排在前面的找得到，第 10 到第 50 名够不着"——候选集本身不完整，不是排序问题。

最终查出来的是一串叠加的缺陷：一行严格小于号、两个没进快照的内存状态、一条四段式的数据失败链。修复后 id-recall@10 从 0.844 回到 0.9784，dist-recall@10 0.9964，倒挂从 0.044 收敛到 0.004，图节点数与 SQL 侧精确对齐到 1,638,397。

这篇文章的主体就是这次排查。开始之前，先用一小节交代清楚"我们在什么东西上踩到了这个坑"。

二、OntoDB 是什么：一个内核装进 12 种数据模型

2.1 拼出来的多模，问题不在性能，在一致性

主流的多模方案本质是"多套存储 + 应用层编排"：关系在 Postgres、图在 Neo4j、向量在 Milvus、时序在 InfluxDB、本体推理在 Jena，靠 ETL 和中间件对齐。

它的痛点很少出现在单点性能上，而出现在缝上：

• 跨系统的写入无法组成一个事务，向量索引与关系数据之间必然存在一个"不一致窗口"，而窗口里的查询结果是错的、且看不出来；
• 同一个业务实体被拆到四五个系统，各存一份，靠 id 映射表勉强对齐；
• 一次查询要串联多家系统，延迟是各家之和，可解释性在拼接处断掉；
• 数据冷热度、安全策略、审计规则要在每一套系统上各配一遍。

我们的选择是不拼：把这 12 种数据模型做进一个 LSM 存储引擎、一套事务体系、和一个查询语言里。下面就是它实际的样子。

2.2 一个 LSM 引擎，12 种数据类型

核心的存储是一套 LSM-Tree，通过键前缀路由区分数据形态：不同前缀走不同的编解码、索引结构和查询算子，但共用同一份 WAL、同一套 compaction、同一块 block cache。前缀划分覆盖 12 种数据类型：

其中四种模型是这次踩坑的主角，也是 AI 场景里最常同时出现的四件套——它们的前缀命名空间和核心数据结构如下：

这四者共享同一套 WAL、同一套 compaction、同一套事务边界——不是"一个进程里装了四个库"，而是"一份数据上开了四种视图"。

图引擎值得一提：字符串 ID 只映射一次，之后全链路走 u32 整数索引，取邻居就是数组下标访问，不做哈希、不比字符串：

id_to_idx: RwLock<HashMap<String, u32>>, // 只在这里做一次字符串映射
idx_to_id: RwLock<Vec<String>>,
adj_out: RwLock<Vec<Vec<(u32, String)>>>, // 出邻居
adj_in: RwLock<Vec<Vec<(u32, String)>>>, // 入邻居

k-hop 遍历的复杂度只与访问到的节点数相关，与图规模无关。遍历本身是 FIFO 队列 + 位图 visited，循环体内全是 u32 运算。企业版进一步换成 CSR 压缩存储（内存约省 50%），并用 Rayon 做并行邻居扩展。

本体层则是把 OWL 2 RL 推理引擎嵌进了存储内核：子类传播、等价类、传递性、对称性、逆属性、子属性等规则在写入时即触发（增量不动点约 50µs/事实），推导结果与原始事实在同一个事务边界内持久化，并记录来源规则与输入事实——inferred_from 让"这条结论从哪几条事实推出来的"可以被追问到具体的写入和规则触发点。对一个要给 Agent 用的数据库来说，可溯源不是加分项，是及格线。

2.3 把十二种模型缝在一起的两根线

第一根：统一实体锚点。 一个字符串同时充当全部模型的键：

EntityId = {namespace}::{class}::{pk}

于是"化合物 A 的关系行""化合物 A 的图顶点""化合物 A 的向量文档""化合物 A 的时序记录"指向的是同一个实体——零映射表、零 ETL、没有"对不齐"的可能。前缀里的 {namespace} 不是装饰，是内核级多租户隔离：本体定义、数据、索引、推理都在命名空间范围内生效，键前缀路由零开销，不会出现"应用层加 tenant_id 容易漏过滤"的问题。

第二根：同一套事务。 一次写入同时触碰多类结构，走的是同一套提交协议（三阶段锁：准备 → 预提交 → 提交，用来避免写锁与索引锁嵌套死锁）。这也是为什么后来那个"幽灵"问题只能靠一致性对账来解决——因为在我们的架构里，图、向量、关系本来就是同一份数据的不同视图，视图之间不对齐，是一种"内部矛盾"，而不是"外部同步延迟"。

数据完整性的最后一道防线在块级：SSTable 每页带 CRC，读路径做哨兵校验，损坏数据被确定性拒绝而不是悄悄吐错值；配合 Raft 副本（企业版）可以自动从健康副本修复。这不是"防御性编程"的口号——后面的排查里会看到，我们自己就被一个"读旧版本"的数据层 bug 咬过。

2.4 一次写入，十二种模型同时就绪；活数据会自己冷

写入侧是原子联动：文档写入 → 图顶点/边 → 三元组 → 推理 → 向量 → 全文/时序/空间索引全部在同一事务内落盘。数据落地的那一刻，它同时是"可被图遍历的""可被向量检索的""可被本体推理的""可被全文检索的"。没有异步索引队列，也就没有"刚写完查不到"的中间态。

除了"写完即就绪"，每条数据从落地开始就在按活数据（Live Data）机制运行：

• 三级半衰期：高频热点 7 小时 → 中频温数据 70 天 → 低频冷数据 2 年
• 三种衰减模型：指数（默认）、线性、对数
• 访问自动激活：每次查询命中自动重置衰减时钟，累加价值得分
• 向量索引联动：高价值数据的向量优先加载到内存，冷数据向磁盘下沉

传统 TTL 是"到点就死"，不理解数据对用户的真实价值；活数据机制让数据"越用越活、不用自动降权"。对 Agent 的长期记忆来说，这比单纯的持久化更重要——记忆不是永恒的，但不该被一刀切清理。

2.5 查询语言也统一了：OntoQL

不是"一个进程里装四套查询解析器"，而是单一查询语言 OntoQL融合关系投影/过滤/聚合、属性图遍历、向量近邻、时序窗口、空间谓词与本体推理；同时标准 SPARQL 1.1 查询（FILTER/OPTIONAL/UNION/EXISTS）也可直接使用。查询优化器会根据模态组合自动选择执行计划，比如"先用关系过滤缩小范围，再走向量近邻，最后在命中集上做图遍历"这类混合查询由优化器下推到存储层完成，不需要应用层拼装。

对"变化"的处理也是一等公民：SUBSCRIBE 原语支持订阅"某靶点家族新增相似分子""某子图边变化""某设备时序异常"这类条件，数据库主动推送，不需要外挂 Kafka 或应用层轮询；内核级 CDC 直接从 WAL 提取变更事件，Flink/Spark 可消费。

协议接入同样是多模的：PostgreSQL（5432）、MySQL（3306）、HTTP REST（7912）三套协议由内核直接解析——不是代理转发，而是协议级实现。现有应用不加中间层就能接入，原有 ORM、BI 工具可以继续用。

2.6 为什么是 Rust

1. 无 GC → 确定性延迟。 向量检索是长尾敏感的，p50 看不出问题而 p99 会跳一个数量级；没有运行时 GC，"驻留内存"这件事不至于在某次搜索中间突然变成一次停顿。
2. 所有权模型 → 锁外计算、锁内交换。 491MB 的 HNSW 快照加载，我们早期把反序列化干在了写锁里，结果是几秒钟内所有并发搜索全部阻塞。修复后的结构是"锁外完成全部反序列化与校验，锁内只做一次指针交换"——而让这个结构成为纪律而不是自觉的，是借用检查器：你没法在持有 &mut 的同时把数据再借出去算别的东西，临界区的边界在类型系统里就是可见的。
3. 单二进制、零运行时 → 部署形态覆盖边缘。 客户拿到的是一个可执行文件，--data-dir 指过去就能起；从边缘服务器到云，跑的是同一份内核代码，不依赖 JVM/Python 运行时。

好，背景交代完了。下面进入正题。

三、一次 HNSW 召回坍塌的完整排查

3.1 现象：Recall@50 低于 Recall@10

数据规模：227 万条 Morgan 指纹（1024 位二进制，Tanimoto 距离）。现象就是开头那两行——Recall@10 ≈ 0.88，Recall@50 ≈ 0.85。

3.2 三次排除，排除掉三个错误假设

我们没急着调参，先做排除。而且用的是分层大样本（500 节点，按 fp popcount 五分位抽样），不是拍 25 个点就下结论：

1. 自检索 sanity check：用图中已存在的节点当查询，看它能否找回自己。结果 self-recall = 1.00（5000 样本下 0.9972）——图是连通且可导航的，排除"图结构崩坏"。
2. 距离口径对照：Tanimoto 是离散距离，可能有大量并列。id 口径与 dist 口径各测一遍，两者只差约 0.018（几乎全是并列距离造成的）——排除"并列造成假象"。
3. efSearch 扫描：从 64 提到 800，召回只从 0.72 涨到 0.89 就见顶——排除"搜索深度不够"。

三次排除之后，剩下的可能性只有一个：真邻居压根不在可达子图上。边被系统性剪坏了，搜索再深也进不去。

3.3 根因一：一行严格小于号

问题出在 HNSW 的多样性剪枝启发式里：

// 对候选邻居 c，检查已被选中的邻居 r 是否"覆盖"了 c
// 若 r 到 c 比 q（新插入节点）到 c 更近，说明 c 由 r 代表即可 → c 冗余、可剪
for r in &selected {
if dist(r, c) < dist(q, c) { // ← 问题在这一行的边界语义
drop(c);
}
}

在连续欧氏空间里，两个距离完全相等的概率是 0，这行怎么写都不出问题。但 Morgan 指纹是 1024 位二进制，Tanimoto 是离散值——并列是常态，不是例外。于是大量数值上并不冗余的新节点，被系统性判为"冗余"剔除。

更隐蔽的是触发条件：

• 建图初期邻居列表远没到上限，剪枝根本不会被触发——所以早期写入的 146 万向量质量是好的；
• 图饱和之后，每次增量插入都会触发剪枝——后续写入的向量入边被反复切断，逐渐沦为孤点。

这解释了全部观测：早期批次正常、后期批次下滑、@50 倒挂、部分区域"几乎什么都搜不到"。

修复两处：并列时放行（不剪），以及保护刚接上的新节点（保证至少一条入边）。

3.4 根因二：44 万个"幽灵"

修完剪枝，召回只回到 0.85 左右。继续查，发现一个更严重的不一致：

HNSW 图内节点数 2,083,259
SQL 中有合法指纹的行数 1,638,397
差 444,862

大量节点存在于 HNSW 里，SQL 侧却查不到对应的指纹。抽查发现这些"幽灵"的 SMILES 都是正常药物分子（阿司匹林类似物那一类），本该有指纹，不是脏数据。

根因是两个纯内存状态没有进快照：

• deleted_keys：哪些向量已被逻辑删除（本应随索引落盘）；
• doc_vectors：哪些 id 当前持有有效向量。

重启后这两个集合清零，于是删除过滤失效，历史被删节点重新漏进搜索结果；增量对账逻辑又因为"图里已经有这个节点"直接跳过，没去核对"它在文档侧其实已经没有指纹了"。搜索时的候选放大系数还写成了 k + 已删数量——44 万的删除量下，等于每次搜索都要扫全图。

泄漏路径的修复是 restore 后全量对账，把图内节点与文档侧做完整比对：

图有节点 + 文档有 fp → noted = 1,638,397 （重建 doc_vectors）
图有节点 + 文档无 fp / 行已删 → ghosts_marked = 444,862 （mark_deleted）
图无节点 + 文档有 fp → 补录
合计 = 2,083,259 = 图内节点数 ✓

随后执行原地 prune（非全量重建）：保留拓扑、全层邻居重写、双向边补全、entry/max_layer 重算，摘除 444,862 个节点耗时 23.1 秒（重建路径是小时级），快照从 959.8MB 瘦到 694.8MB（−27.6%），over_fetch 从 8× 回落到 2×。

3.5 根因三：四段失败链，不是一个 bug

排查没有停在"对账修好了"。我们继续追"这些正常分子的 fp 为什么会变成 NULL"——这才是真正的源头。结论是四段失败叠加，任一段单独都不会出事故：

1. A · 导入用了不完整的 id 索引做 keyset 分页，导致分区断流，漏写约 65~78 万行的指纹；但导入日志显示的完成数约等于全表行数，当时以为已 100%。
2. B · 覆盖率验证抽样偏差：check_fp_coverage.py 只抽查 7 个 id，refill_gaps.py 只查 CHEMBL1-9 前缀——全落在未漏写区域，假收口。
3. C · chem 表批量导入的 INSERT 列清单不含 fp 列，新写入的版本覆盖了有 fp 的旧行，产生无 fp 的最新版本。
4. D · pass-2 版本选择 bug（w_seq == seq 匹配 + snapshot_sst_handles 层序 L6→L0 反转）：向量 backfill 恰好跑在这个 bug 期间，层序从旧到新扫描、seq 被 clean_index 清零时读到了导入前的旧版本（有 fp），把旧版本指纹索引进图，而活版本无 fp——这就是 44.4 万差额的精确来源。

这里有一个值得单独说的设计教训。我们这套索引的版本权威来自 LSM-Tree 的物理层序（newest-first + first-seen-wins），而不是 seq_no。层序是存储引擎自己维护、不可篡改的事实；seq 是元数据，可以被重整、清零、碰撞。这个取舍在这次事故里救了我们——D 段的病灶正是"用 seq 代替层序"。

生产端三条修复：pass-2 改走层序优先；prune_ids 按 id 去重（保留与 doc_vectors 匹配的那个，防止同 id 双节点一起存活）；chem 导入列清单补全 fp。覆盖率验证从 7 点抽查升级为"全量 COUNT + 分区分层抽样"。

排查过程中还顺带修掉 planner 一处结构性问题：remaining_filter 被包在 Limit 节点之上，计划形状是 Filter(Limit(SeqScan))，而 SQL 语义要求 Limit(Filter(SeqScan))——导致 WHERE ... LIMIT N 只返回 N−1 行，ORDER BY ... LIMIT 场景更是返回"错的行"而非"少的行"。

3.6 结果

最终验收采用 500 节点分层抽样（fp popcount 五分位 × 100）、GT 装载 1,638,397 条（与节点数逐位一致）：

所有闸门（id≥0.968 / dist@10≥0.990 / dist@50≥0.985 / self≥0.995 / ghost=0 / 节点数精确）全部通过。

3.7 五个 bug，其实是同一类病

这一路共修掉 5 个查询正确性 bug：equality 等值点查返回双行、ghost 泄漏、pass-2 版本选反、NOT 谓词被当成列名、以及 planner 的 Filter/Limit 形状错误。

它们底层是同一个病："版本合流必须走层序、谓词归属必须覆盖所有算子形态"这条纪律，之前只在部分代码路径上落地了。修复方式不是逐个打补丁，而是收敛到一个公共迭代器——整族免疫，而不是这一次修好。

顺带记一条通用规则：凡输出顺序承载语义的路径（range 扫描、keyset 分页、层序扫描），去重一律用保序实现。我们最初给 equality 加去重时用了 sort() + dedup()，打乱了 range 的索引序，导致分页重复扫描、装载数虚高到 1.97M、召回掉到 0.76——换成保序去重后立刻恢复。

四、排查之后：从"人工深挖"到"自动发现"

这次事故最值得反思的一点是：上述 5 个 bug，没有一个是监控发现的，全靠人工深挖。 修完 bug 只是第一步，第二步是让同类问题以后能被自动看见：

• schema API 暴露向量索引状态：nodes / deleted_keys / ready / m / ef_construction，探针不再依赖日志格式。
• reconcile 日志分级告警：冷启动首次对账允许个位数 ghost（快照窗口内写入属正常）；冷启动后出现任何非零 → WARN；占比 > 1% 建议 COMPACT；> 10 万 → ERROR。
• 独立探针拆分：probe_vec_nodes.py / probe_vec_ghost.py / probe_vec_self.py（秒级健康检查）/ probe_ready_gate.py（启动窗口负向探针），各自可跑。
• 启动门闩：对账完成前向量查询返回明确错误，而不是静默返回脏结果——用约 28 秒的"等待可用"换"不返回错数据"。
• k8s 探针拆分：liveness 立即返回 200，readiness 等待 ready=true，避免对账未完成时探针失败触发无限重启循环。

五、共建与邀约

OntoDB 核心内核以开源生态层 + 闭源企业能力双轨推进。我们想找的是：

• 在真实场景里用得上"向量 + 图 + 本体 + 流"的团队——来仓库提 Issue 聊场景，哪怕是"你这个设计在我的场景下不成立"这种；
• 愿意补 client SDK、文档、查询算子的同学——crates/ 下每个 crate 边界写得比较清楚，PR 门槛不高；
• 想写点东西的人——欢迎写"我用 OntoDB 接了哪个 Agent、哪张知识图谱"，踩坑文比赞美文受欢迎得多。

给评论区留一个我们确实没想透的问题：

在离散距离空间（二进制指纹、量化嵌入）里，HNSW 的多样性剪枝该怎么处理"并列距离"？并列放行，还是引入第二判据（比如按层序或 id 稳定排序）？你们的实现是怎么处理的，有没有踩过类似的坑？

仓库在这里，欢迎 clone、跑 Demo、开 Issue：

https://github.com/jianzhuguo/ontodb

# 前置：Rust 1.77+
git clone https://github.com/jianzhuguo/ontodb.git
cd ontodb
cargo build --release
./target/release/ontodb-server --data-dir ./data --http 0.0.0.0:7912

六、In Rust We Trust

谢谢 Rust 中文社区，谢谢各位Ruster，我们产品已经开源发布，现在轮到社区来用、来骂、来改、来共建。

*（本文性能数字与故障复盘均来自仓库基准报告与真实排查记录；最终验收采用 500 节点分层抽样与 5000 节点 self-recall 验证。未覆盖项——并发压测、kill-9 崩溃注入、千万级规模边界、*deleted_keys/doc_vectors 持久化——不在本文宣称范围内，不做隐藏。）

Zed  ──ACP (JSON-RPC over stdio)──▶  rpi --acp  ──spawn──▶  rpi --mode rpc  (每会话一个)

rpi-acp 是个 cdylib 扩展，做三件事：抢 stdio、说 ACP v1、给每个会话挂一个 rpi --mode rpc 子进程。桥接层自己不跑模型——tools、models、auth、skills 全在子进程里，所以行为跟终端里跑 rpi 完全一致。

关键机制：抢夺 stdio

宿主默认会 drain stdin，扩展就拿不到 stdio，ACP server 无从谈起。解法：带 --acp 时，扩展在注册阶段声明 {"ownsStdio": true}，宿主随即停止 drain，改走 StdioLifecycle，把 stdin/stdout 交给扩展。

从终端直接跑 --acp 会快速失败（一条消息 + exit 2），而不是空转。要注册用 rpi --install-zed。

事件映射

流式文本用累积快照 + finalText 去重，不重发已发过的 chunk。

会话持久化

稳定 UUID，原生 JSONL 历史落在 ~/.rpi/agent/acp/sessions（可用 RPI_ACP_SESSION_DIR 覆盖），进程退出后仍在。session/load 恢复并重放，session/resume 恢复但不重放。未知会话返回错误，不静默开空对话。

权限与问题扩展

• 权限：插件弹窗（如 bash 确认）映射成标准 session/request_permission，用户选择回传插件。默认带 --permission-gate。
• 问题：ACP v1 没有通用多选方法，于是双方在 initialize 里用 _meta: {"pi-rust/questions": 1} 协商。只有广告了 v1 的客户端才收到 _rpi/request_question；超时默认 300s，配套 _rpi/dialog_closed 通知回收 UI。

安装配置

rpi install rpi-acp    # 或 task install

Zed settings.json：

{ "agent_servers": { "rpi": { "type": "custom", "command": "rpi", "args": ["--acp"] } } }

args 可透传普通 flag，如 ["--acp", "--model", "gateway/model"]。--acp 会自动注册到 Zed（幂等、原子写、保留 JSONC 注释）；设 RPI_ACP_NO_AUTO_REGISTER_ZED=1 可关掉。

独立二进制 rpi-acp-bridge

同样的 server 也能编成独立二进制，原生拥有 stdin/stdout，不需要 ownsStdio，可直接对着 stock rpi 跑。找 agent 的顺序：RPI_BIN → 自身 → 兄弟文件 → PATH。

cargo build --release -p rpi-acp --bin rpi-acp-bridge
task pack-acp   # 打包进 ACP Registry

相关链接

• 🏠 官网与文档：https://rpi.laofu.online/
• 📦 核心仓库：bigfish1913/pi-rust
• 🔌 扩展仓库：pi-rust/rpi-package
• 📚 软件包目录：https://rpi.laofu.online/packages.html
• ✍️ 个人博客：https://blog.laofu.online/

数据库 ↔ 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