Rust 编译器错误码 E0200 解析：为什么 unsafe trait 必须配合 unsafe impl

本指南围绕 rustc 错误码 E0200（"unsafe trait 被以非 unsafe 的方式实现"）展开，从触发条件、修复方法到编译器内部的诊断实现逐一剖析。读完你不仅能定位并修复这类编译错误，还能理解 unsafety.rs 中安全规则检查的完整分支逻辑，以及它与 E0199、E0569 两个相邻错误码的区别。

错误速览

rustc 官方错误文档 E0200.md 对该错误的描述只有一句话：

An unsafe trait was implemented without an unsafe implementation.

即：一个被标记为 unsafe 的 trait，在实现时却没有写上 unsafe impl。Rust 的安全保证机制规定，unsafe trait 隐含着一组"编译器无法替你验证"的不变量（invariants），只有显式写出 unsafe impl，实现者才是在以自身名义声明"我已人工确认这些不变量成立"。编译器用 E0200 强制这一声明行为可见且可审计。

触发场景与错误示例

下面的代码是错误文档给出的最小复现（与回归测试 tests/ui/error-codes/E0200.rs 完全一致）：

struct Foo;

unsafe trait Bar { }

impl Bar for Foo { } // error!

• unsafe trait Bar 定义了一个 unsafe trait；
• impl Bar for Foo 却省略了 unsafe 关键字，于是编译直接失败。

实际的编译器报错信息（见 E0200.stderr）如下：

error[E0200]: the trait `Bar` requires an `unsafe impl` declaration
  --> E0200.rs:5:1
   |
LL | impl Bar for Foo { }
   | ^^^^^^^^^^^^^^^^
   |
   = note: the trait `Bar` enforces invariants that the compiler can't check. Review the trait documentation and make sure this implementation upholds those invariants before adding the `unsafe` keyword
help: add `unsafe` to this trait implementation
   |
LL | unsafe impl Bar for Foo { }
   | ++++++

正确修复：把 impl 显式标为 unsafe

修复方式非常简单——为 impl 块补上 unsafe 关键字：

struct Foo;

unsafe trait Bar { }

unsafe impl Bar for Foo { } // ok!

编译器在报告 E0200 时还会自动附带一条机器可采纳程度为 MaybeIncorrect 的修改建议（在源码中是 unsafety.rs 中 Applicability::MaybeIncorrect 的自动修复提示），即在 impl 起始位置插入 unsafe 前缀，正如上方 stderr 中 ++++++ 高亮所示。

需要强调的是：unsafe impl 中的 unsafe 不是可有可无的装饰。它等同于一句负责任的声明——"此 unsafe trait 要求的不变量（例如内存安全契约、Send/Sync 之外的线程约束等）我已逐条审查并保证满足"。编译器的 note 信息也直接提醒你：请先阅读 trait 文档，确认实现确实满足其不变量后，再加 unsafe。

编译器底层如何检查并报告 E0200

E0200 的产生完全由一致性检查（coherence checking）阶段的一个专用模块负责。入口位于 coherence/mod.rs 的 coherent_trait 查询：它会为某个 trait 遍历所有本地 impl，逐个执行多项检查，其中第 183 行就是本错误的检查点：

res = res
    .and(check_impl(tcx, impl_def_id, trait_ref, trait_def, impl_header.polarity))
    .and(check_object_overlap(tcx, impl_def_id, trait_ref))
    .and(unsafety::check_item(tcx, impl_def_id, impl_header, trait_def)) // ← E0199/E0200/E0569
    .and(tcx.ensure_result().orphan_check_impl(impl_def_id))
    .and(builtin::check_trait(tcx, def_id, impl_def_id, impl_header));

也就是说，E0200 并非词法/语法层面的问题，而是在 HIR 语义分析之后、类型一致性检查阶段（rustc_hir_analysis）才被捕获。

核心匹配逻辑

真正产生 E0200 的判断位于 unsafety.rs 的 check_item 函数，它把四元组作为匹配对象：

match (trait_def_safety, unsafe_attr, trait_header.safety, trait_header.polarity) {
    (Safety::Unsafe, _, Safety::Safe, Positive) => { /* 报告 E0200 */ }
    ...
}

四个维度分别是：

维度	含义	取值示例
trait_def_safety	trait 定义本身的安全级别	Safe / Unsafe
unsafe_attr	impl 泛型参数上是否带有需要 unsafe 的属性	None / Some("may_dangle")
trait_header.safety	impl 块是否声明为 unsafe	Safe / Unsafe
trait_header.polarity	impl 极性	Positive（正向实现）/ Negative（负向实现）

当 trait 是 Unsafe、而 impl 头是 Safe、且为正向实现时，命中 (Safety::Unsafe, _, Safety::Safe, Positive) 分支，check_item 立即返回带 E0200 码的错误。

一个特殊分支：含 unsafe 字段的 Copy 实现

值得留意的是函数开头的特判逻辑：当被实现的 trait 是语言项 Copy 时，trait 自身的 safety 不再直接采用声明值，而是看 Self 类型是否包含 unsafe 字段：

let trait_def_safety = if is_copy {
    // If `Self` has unsafe fields, `Copy` is unsafe to implement.
    if trait_header.trait_ref.skip_binder().self_ty().has_unsafe_fields() {
        rustc_hir::Safety::Unsafe
    } else {
        rustc_hir::Safety::Safe
    }
} else {
    trait_def.safety
};

从源码结构可以推断：如果一个类型含有 unsafe 字段（例如 unsafe struct/字段本身带有未检查的不变量），那么对它实现 Copy 会把这些不变量隐式传播给所有拷贝副本，风险极高，因此 rustc 会"临时"把该 Copy impl 视为 unsafe trait 的实现。此时若写成普通 impl Copy，同样触发 E0200，只是 note 文字换成专门针对 unsafe 字段的版本：

the trait `Copy` cannot be safely implemented for `Foo`
because it has unsafe fields. Review the invariants
of those fields before adding an `unsafe impl`

错误信息中 note 的源码出处

无论是普通 unsafe trait 还是上述 Copy 特例，报错都带有一段解释性 note。普通路径下的文案直接内嵌在 unsafety.rs 中：

the trait `X` enforces invariants that the compiler can't check.
Review the trait documentation and make sure this implementation
upholds those invariants before adding the `unsafe` keyword

建议修改 add unsafe to this trait implementation 则由 with_span_suggestion_verbose 附加，提示在 impl 起点插入 unsafe ，且应用建议前应人工复核，因此被标记为 MaybeIncorrect（而非无脑可应用的 MachineApplicable）。

三个"亲缘"错误码：E0200 / E0199 / E0569 对比

同一段 match 中还有两个与 unsafe impl 声明相关的兄弟错误，它们共同构成了完整规则集：

错误码	触发场景	修复建议
E0200	trait 是 unsafe，impl 却漏写 unsafe	在 impl 前加 unsafe
E0199	trait 是安全的，impl 却多写了 unsafe	删除多余的 unsafe
E0569	trait 虽安全，但 impl 泛型带 may_dangle 等需要 unsafe 的属性	加上 unsafe impl

对应源码分支分别是：

• (Safety::Safe, None, Safety::Unsafe, Positive) → 报 E0199，提示语 "implementing the trait X is not unsafe"，并给出删除 unsafe 的可应用建议（MachineApplicable）。错误文档见 E0199.md，回归测试见 tests/ui/error-codes/E0199.rs；
• (Safety::Safe, Some(attr_name), Safety::Safe, Positive) → 报 E0569，提示语 "requires an unsafe impl declaration due to #[{attr}] attribute"。这里 unsafe_attr 来自对 impl 泛型参数中 pure_wrt_drop（即 #[may_dangle] 语义）的探测，见 E0569.md；
• 另有 (_, _, Safety::Unsafe, Negative) 分支专门负责"unsafe 负向 impl"（即 unsafe impl !Trait for T），该写法本身非法，已在 AST 校验阶段提前报错，此处仅做断言兜底。

由此可以看出设计思路：安全 trait 默认应被安全实现，unsafe trait 或被特殊属性标记的 trait 必须显式 unsafe 实现，任何一边的不匹配都会在 coherence 阶段被拦截。

如何在命令行查阅该错误

rustc 内置了错误码解释系统。遇到 E0200 时，除了直接阅读完整报错，还可以用以下命令调出与本文对应文档完全一致的说明：

rustc --explain E0200

在 rustc 源码仓库中，该命令展示的内容即来自 compiler/rustc_error_codes/src/error_codes/E0200.md，它由 rustc_error_codes crate 统一打包进编译器。也就是说，本文开头引用的错误描述、错误示例与修复示例，就是你本地 rustc --explain E0200 的真实输出。

小结

E0200 的修复成本极低（补一个 unsafe），但它承载的安全语义却很重：它确保任何 unsafe trait 的实现者在代码层面留下明确且可被 Code Review、静态审计工具检索到的"我已核验不变量"签名。如果你理解了 unsafety.rs 中那个四元组 match，就等于同时掌握了 E0200、E0199、E0569 三个错误码的统一判据：trait 声明安全性、属性要求与 impl 声明安全性三者必须一致。