Gitdot：Rust 构建的反 AI 代码托管平台架构解析

在 GitHub Copilot 席卷开发者工具市场的当下，一个名为 Gitdot 的新项目选择了一条截然不同的道路。这个用 Rust 构建的开源代码托管平台不仅拒绝集成 AI 功能，更将其作为核心产品哲学公开宣示。这种反潮流姿态背后，是一整套经过深思熟虑的技术架构与工程实践。

反 AI 作为产品立场

Gitdot 在 FAQ 中明确将 AI 列入 "不会有的功能" 清单。其创始团队认为，AI 应当被视为 "实现细节" 而非产品卖点，当前业界对 AI 的过度依赖往往成为 "糟糕设计的创可贴"。这种立场并非技术保守主义，而是对产品本质的回归 —— 代码托管平台的核心价值在于代码本身的质量与可维护性，而非辅助生成的效率幻觉。

这种哲学直接影响了技术选型。团队选择 Rust 而非 Go 或 Python，部分原因是 "GitHub 已经存在，而 Gitea 也是 Go 写的"。Rust 的性能特性与内存安全保证，为构建一个 "感觉更快" 的平台提供了基础。

六边形架构与领域驱动设计

Gitdot 的后端架构经历了从单体到多服务的演进，但始终保持着清晰的结构边界。项目采用六边形架构（Hexagonal Architecture）与领域驱动设计（DDD）原则，将系统划分为以下核心 crate：

• gitdot-core：领域逻辑层，包含 Service、Repository、Model 等概念
• gitdot-server：HTTP 层，仅包含 Axum 路由与 Handler
• gitdot-api：API 契约层，定义请求 / 响应类型与端点规范
• gitdot-axum：共享中间件层，包含日志、限流、认证等通用组件

这种分层带来的可维护性在团队引入 Claude Code 辅助开发时得到验证 ——"可预测的结构为 AI 提供了清晰的模式遵循，输出质量更高且易于审查"。

性能优先的工程实践

Gitdot 将页面渲染时间目标设定为 100 毫秒以内 —— 这是 Jakob Nielsen 提出的 "即时响应" 阈值。为实现这一目标，团队采取了一系列激进的工程决策：

无加载动画策略：传统 Web 应用依赖加载指示器掩盖延迟，Gitdot 选择从架构层面消除延迟本身。通过 Shared Web Workers、IndexedDB 缓存，以及利用 Git 对象不可变性（blobs 与 trees 一旦写入即不变）的特性，实现零成本抽象 —— 页面只会越加载越快。

无导航栏设计：Gitdot 将浏览器的地址栏视为页面标题，通过 "Beautiful URLs"（如 gitdot.io/bkdevs/gitdot/src/handler.rs）替代传统导航结构。键盘快捷键系统（h 返回首页、p 文件搜索、j/k 列表导航）将交互效率提升至 IDE 级别。

流式处理：Git 操作可能涉及 GB 级数据传输，Gitdot 采用流式处理避免内存驻留，当前阶段通过 git http-backend CGI 程序代理，计划未来用原生 Rust 实现替换。

多服务演进路径

从 2025 年 12 月的单服务器原型到如今的三服务架构，Gitdot 的演进体现了 "按边界拆分" 而非 "按规模拆分" 的架构哲学：

1. gitdot-server：核心 API 与 Git HTTP 服务
2. gitdot-auth：独立认证服务，支持邮箱验证码、GitHub OAuth、设备码流程
3. gitdot-metrics：高吞吐、fire-and-forget 的埋点数据收集

每个服务共享 gitdot-core 的领域逻辑与 gitdot-axum 的中间件组件，部署与扩缩容相互独立。这种设计在当前规模下或许显得过度，但团队认为 "边界清晰意味着未来合并或再次拆分都不会是重写"。

可落地的架构决策清单

对于希望借鉴 Gitdot 经验的团队，以下决策点具有参考价值：

技术选型：Rust + Axum 组合在类型安全与性能之间取得平衡，但学习曲线陡峭。团队建议 "语言在服务端层其实影响不大，大部分延迟来自数据库与 Git 本身"。

分层策略：将 API 契约独立为 crate（gitdot-api）使服务端与客户端（包括 CLI）天然保持一致，消除版本同步问题。

认证设计：复用 Git 自带的凭证系统（git credential approve）而非自建存储，用户 token 自动存入系统钥匙串，实现 "无感知认证"。

数据库托管：早期使用 Supabase 快速启动，后期迁移至自托管 Postgres 以减少网络往返延迟。关键权衡在于 "托管服务的便利性与延迟成本"。

局限与展望

Gitdot 仍处于早期阶段（v0.2 预计 2026 年 7 月发布），当前实现存在明显局限：Git 服务仍依赖 CGI 代理，SSH 支持尚未实现，端到端加密 Git 协议仍在规划中。

但其价值或许不在于立即替代 GitHub，而在于证明了一种可能性：在 AI 主导的行业叙事中，依然可以通过扎实的技术架构与明确的产品哲学，构建出令人耳目一新的开发者工具。正如其设计文档所言："工程是情感 endeavor，我们所做的决定往往并非理性的产物，而是源于自身的感性。" Gitdot 的选择，或许正是这种感性的诚实表达。

资料来源

• Gitdot 官方网站与 FAQ：https://gitdot.io
• 后端架构演进设计文档：https://gitdot.io/designs/how-gitdot-backend-evolved
• 产品设计原则文档：https://gitdot.io/designs/gitdot-designed-by-developers

web