大多数Rust项目的第一行代码是网络层、存储引擎或者异步调度。NEXUS不是。它的第一个crate叫nx-error——专门用来处理错误。

这个选择不是风格偏好，是架构刚需。NEXUS围绕服务边界、类型化契约和跨层一致的失败表示来构建。错误不是事后补丁，是整个系统的元数据基础设施。

打开网易新闻 查看精彩图片

API设计：小表面，大用途

核心目标让领域错误易于定义，同时对下游系统有用——HTTP层、日志、指标、仪表盘、运维工具都能消费。

#[error]pub enum DatabaseError {    #[error(message = "Connection lost", status = 503, code = "DB_CONN_LOST")]    ConnectionLost,    #[error(message = "Entity not found", status = 404, code = "DB_NOT_FOUND")]    NotFound,}

定义一次，自动保留源上下文，只在有意义的地方追加诊断细节。调用点不需要自定义映射胶水：

fn read_snapshot(path: &str) -> Result {    std::fs::read_to_string(path).map_err(DatabaseError::from)}

需要运维上下文时，在上下文实际存在的地方 enrichment：

.with_message("Failed to load configuration").with_help("Check whether config.json exists")
为什么不用现成的

Rust生态不缺错误工具：thiserror擅长库级类型错误，anyhow适合应用级聚合，miette主攻诊断型CLI。但NEXUS的约束更窄也更苛刻。

关键矛盾：同一失败对不同受众的序列化不能相同。外部客户端要稳定错误码、简洁消息、状态值；运维侧要完整源链、上下文细节、修复提示、可索引结构。这种分离必须是头等设计目标，而非HTTP层临时拼凑。