推文

@fireandstart · 2026-10-15 03:34

把大型 Rust workspace 拆成 crate，真正值得讨论的不是“拆得越细越好”，而是边界是否对应稳定的依赖关系和团队职责。ScopeDB 的 27 个 crate 分成开发工具、集成测试、CLI、可复用库和产品内部模块，这种分层让哪些东西服务外部使用者、哪些只是仓库内部实现，一眼就能区分。 构建时间也不能只看总 crate 数：Cargo 可以并行编译独立 crate，未受影响的部分还能跳过；但如果改动经常穿透多个 crate，接口维护、依赖协调和 CI 编排也会变成成本。帖里给出的 M4 Max 冷调试构建约 1 分钟，是这套工作区的基线；Charlie Marsh 提到 uv 拆分后增量构建提速 30–40%，则是另一个项目的案例，不能直接当成 ScopeDB 的收益。 我更想看到后续数据按冷构建、增量构建、常见修改范围和 CI 缓存命中率分别呈现。这样才能判断拆分到底缩短了反馈回路，还是只是把复杂度从单个 crate 转移到依赖图与发布流程。Rust 项目里，crate 数量本身不是目标；让常见改动只重编译必要部分，同时保持边界可理解，才是可持续的优化。

曝光 23 · 评论 0 · 点赞 0 · 书签 0