【Rust日报】2026-11-10 改一个标签要 8.4 毫秒
内容提要
本文汇总多篇Rust资讯：GPUI状态模型因整树更新成本高（改标签需8.4毫秒）而需重构API实现细粒度更新；Cot 0.8新增事务、迁移回滚、排序与文本匹配查询，路由器改用matchit并移除axum；rust-analyzer #353新增诊断、补全及多项修复；tellus集群故障注入测试中，45分钟5352个请求仅8个失败、0次违规，两个bug已修复。
延伸解读
GPUI 状态模型的成本根源
GPUI 的 notify 只带 entity id，Rust 的 &mut 没有写屏障，框架无法知道哪个字段变了，导致没有有效 .cached() 边界的 view 全部重跑。文章实测 3000 行时改一个标签要 8.4 ms，每多 1000 行约加 3 ms，悬停、按键甚至写成原值成本都接近，因为成本跟着整棵树走。这说明问题不在操作本身，而在更新粒度太粗。
细粒度更新的代价与真实收益
要让一个标签单独更新，这个标签自己得是一个 view，带 entity、Render、订阅、存值和手写判断，等于拆掉现有 API。gpui-fast 把 3000 行的标签更新从 8.4 ms 降到 3.4 ms，但状态共享后同一帧 retention 反而慢 11%。Zed 团队测到 retention 在普通负载上比关掉慢 1% 到 3%，微基准收益对不上真实场景，文本编辑器还绕开了 GPUI 的布局和 view 语义。
Cot 0.8 的实用改进与取舍
Cot 0.8 补上了事务和迁移回滚：事务对象未 commit 被 drop 会自动回滚，事务上再 begin 得到可单独提交或回滚的 savepoint。查询增加 order_by 和 contains 等文本匹配，用户输入中的 % 和 _ 按字面量转义。迁移回滚会保留指定迁移本身，撤掉其后的迁移并处理跨 app 依赖。路由器改用 matchit 的 radix trie，构建时拒绝歧义路由，并去掉 axum 直接使用 hyper 以减少依赖和编译时间。
tellus 故障注入的边界
45 分钟 5352 个请求仅 8 个失败、0 次违规，但文章明确 0 次违规不等于集群正确。这套故障没有模拟抖动网络、单向链路、时钟偏移和过载。8 个失败请求中 5 个紧跟 kill、3 个紧跟优雅停机，分区后没有；修复包括关闭 DNS 缓存、Leaving 阶段健康检查回 503 并至少再跑 5 秒。录演示时终端 UI 轮询导致 1552 个请求失败 1 个，原因尚未查到。
Q&A
GPUI 改一个标签为什么需要 8.4 毫秒？
GPUI 的状态更新以 entity 为单位，调用 cx.notify() 后，没有有效 .cached() 边界的 view 会重跑。在 3000 个存活行、每行一个带缓存 view 的场景下，改一个标签需要 8.4 ms，且成本随整棵树增长，每多 1000 行约增加 3 ms。
Cot 0.8 在数据库和查询方面新增了哪些功能？
Cot 0.8 的 ORM 新增事务支持：Database::begin 开启事务，未 commit 时 drop 会自动回滚，事务上再 begin 得到 savepoint。查询新增 order_by 排序（支持 asc/desc、nulls_first/last、by_values）以及 contains、starts_with、ends_with 和忽略大小写的 icontains 等文本匹配，用户输入的 % 和 _ 会按字面量转义。
Cot 0.8 的迁移回滚怎么用？
使用 cot migration rollback 0002 --dry-run 可以只打印计划。指定的迁移本身会保留，它后面的迁移会被撤掉，跨 app 的依赖也会一起撤。也可以传完整迁移名，或传 0 撤掉该 app 的全部迁移。另外 cot migration graph --format mermaid -o migrations.mmd 可导出依赖图。
rust-analyzer changelog #353 有哪些值得关注的新功能和修复？
新功能包括：为 Linux glibc 发行版启用 jemalloc；新增只对带 drop glue 类型显示隐式 drop 提示的选项；新增 invalid-pat-path-res、match-inherited-imm-ref-with-mut-ref-pat、unresolved-associated-type 三项诊断。修复涉及 problem matcher 位置匹配、dyn trait 补全、强制转换逻辑对齐 rustc、MIR 求值 panic、#[repr(i28)] 补全、generate_function 泛型 panic 等。
tellus 集群故障注入测试的结果如何？
在 2026 年 10 月一次 45 分钟运行中，验证器记录到 0 次违规，发出的 5352 个请求中有 8 个失败。8 个失败请求中 5 个紧跟在 kill 后面，3 个紧跟在优雅停机后面，分区后面没有失败。
tellus 测试中发现的两个 bug 是什么，如何修复的？
第一个 bug：分区后失败一侧的两个节点几乎同时移出并重启，其中一个查询共享 DNS 名时只看到 4 个节点，且 tellus-bootstrap-dns 缓存了旧应答。修复是一行：builder.options_mut().cache_size = 0。第二个 bug：SIGTERM 路径上节点已离开集群但健康检查继续回 200，导致 Caddy 仍发请求而失败。修复是进入 Leaving 阶段后健康检查回 503 并至少再跑 5 秒。两个 bug 都在 tellus 0.4.0 之前修好。
