深入 Rust ↔ C FFI：六大语言差异与边界安全实践（comprehensive-rust 课程精讲）

本文以 Google Android 团队维护的 Rust 课程 comprehensive-rust 中 Rust ↔ C 一节为核心，系统拆解 Rust 与 C 在跨语言边界（FFI）上必须面对的六大语义差异——错误处理、字符串、可空性、所有权、回调与 Panic，并结合仓库中的代码示例与配套讲义，给出每一项差异的成因、后果与在边界处的正确应对方案。读完本文，你将掌握在 Rust 与 C 之间设计安全、可维护的 FFI 接口所需的完整知识框架。

背景：为什么语言差异是 FFI 的第一道坎

在 comprehensive-rust 的 语言互操作章节 中，课程首先点明一个理想场景：Rust 与外部语言（课程以 C++ 为主要对象）最好能互相直接调用对方的方法。但这个理想几乎无法直接达成，原因有二：不同语言有不同语义，映射意味着取舍；Rust 与 C++ 都未提供稳定的 ABI，难以建立在稳固的基础之上。

于是，language-differences 小节 给出了一张关键的关系图：Rust 与 "C++" 之间的调用，实际上都以 C 作为最低公共分母（lowest common denominator） 中转。换言之：

• Rust ↔ C 直接互操作；
• "C++" ↔ C 直接互操作；
• Rust ↔ "C++" 则要经过 C 间接完成。

课程明确指出，把 C 当作最低公共分母意味着 Rust 和 C++ 的大量丰富语义会在此丢失，每一次翻译转换都潜藏着语义损失（semantic loss）、运行时开销（runtime overhead）与微妙的 bug（subtle bugs）。这正是我们首先要理解 Rust ↔ C 语言差异的根本原因——它不仅是语法层面的不同，更是类型系统、内存模型与错误模型之间的鸿沟。

Rust ↔ C 六大语言差异全景对照

Rust ↔ C 讲义 用一张对照表概括了两门语言在六大核心关注点上的根本分歧：

Concern（关注点）	Rust	C
Errors（错误）	Result<T, E>、Option<T>	Magic return values（魔法返回值）、out-parameters（出参）、全局 errno
Strings（字符串）	&str/String（UTF-8、长度已知）	Null-terminated char*（空终止），编码未定义
Nullability（可空性）	通过 Option<T> 显式表达	任何指针都可能为 null
Ownership（所有权）	Affine types（仿射类型）、lifetimes（生命周期）	靠约定（conventions）
Callbacks（回调）	Fn/FnMut/FnOnce 闭包	函数指针 + void* userdata
Panics（恐慌）	栈展开（stack unwinding）或 abort	abort

这张表是理解整个 FFI 安全性的纲领。下面逐一深入剖析每一项差异的具体表现、典型陷阱与仓库中的佐证。

Errors：从 Result<T, E> 到魔法返回值与 errno

差异本质

Rust 的函数通过 Result<T, E> 显式返回成功值或错误值，用 Option<T> 表达"可能没有结果"；而 C 语言没有内建的错误类型，实践中常见的错误传递方式有三种：

• Magic return values（魔法返回值）：在正常返回值范围内预留一个特殊值表示错误，例如 -1、NULL、EOF；
• Out-parameters（出参）：通过指针参数带回结果，函数返回值只表示成败；
• 全局 errno：出错时设置进程级的全局错误号，调用方事后读取。

边界处的后果

课程在 <details> 备注中给出了两个关键提醒：

1. 必须把 Result 转换以遵守 C 的约定。也就是说，当 Rust 函数要导出给 C 调用时，不能直接把 Result<T, E> 穿过边界，而需要将其折叠成 C 能理解的返回值约定（例如返回错误码、或通过出参带回数据）。
2. C 侧很容易忘记检查错误。由于错误检查完全依赖调用方自觉（没有类型系统强制），漏检错误是 C 侧最常见的隐患，而这在 Rust 一侧是由 Result 的类型系统强制保证的。

从仓库的 语言互操作章节 可以看到，这种"每翻译一次就损失一次语义"的困境在错误上表现得尤为明显：Rust 丰富的错误信息经过 C 边界后，往往只剩下一个整数错误码。

Strings：&str/String 与空终止 char* 的三重代价

差异本质

Rust 的字符串是 UTF-8 编码、长度已知的字节序列（&str 是切片，String 是拥有所有权的堆字符串）；而 C 的字符串是 空终止的 char*，编码完全未定义（由调用方约定）。

边界处的三大陷阱

课程 <details> 备注明确指出字符串转换的三重代价：

1. 转换成本（Conversion cost）：把 C 的 char* 转成 Rust 的 &str/String 通常需要拷贝与校验；把 Rust 字符串传给 C 也可能需要重新分配内存来追加终止符。
2. Null 字节导致截断（null bytes in Rust strings cause truncation）：Rust 字符串内部是允许包含 \0 字节的（例如二进制数据），但如果原样传给 C 的空终止 API，C 侧会在第一个 \0 处截断，产生静默的数据丢失。
3. 入口处的 UTF-8 验证（UTF-8 validation on ingress）：C 的 char* 不保证编码，进入 Rust 世界时必须做 UTF-8 校验，否则无法安全构造 &str。

仓库佐证：三种文本表示的转换

配套讲义 representations.md 用一个可编辑示例直观展示了三种文本表示方式：

fn main() {
    let c_repr = b"Hello, C\0";            // C 表示：空终止
    let cc_repr = (b"Hello, C++\0", 10u32); // C++ 表示：指针 + 显式长度
    let rust_repr = (b"Hello, Rust", 11);   // Rust 表示：字节 + 长度
}

同一段文本，三种语言各有一套表示习惯，彼此之间转换极易出错。讲义给出的转换代码演示了如何把每种原始表示转成 Rust 字符串切片：

// C 表示 → Rust
unsafe {
    let ptr = c_repr.as_ptr() as *const i8;
    let c: &str = std::ffi::CStr::from_ptr(ptr).to_str().unwrap();
    println!("{c}");
};

// C++ 表示（指针 + 长度）→ Rust
unsafe {
    let ptr = cc_repr.0.as_ptr();
    let bytes = std::slice::from_raw_parts(ptr, cc_repr.1);
    let cc: &str = std::str::from_utf8_unchecked(bytes);
    println!("{cc}");
};

注意这里 CStr::from_ptr 与 to_str() 的组合正是"入口处 UTF-8 验证"的体现：to_str() 会校验字节是否为合法 UTF-8，返回 Result；而 from_utf8_unchecked 则把校验责任完全交给调用者。讲义还补充了一个实用细节：Rust 有 C 前缀的字符串字面量（c-string literal），会在末尾自动追加空字节，例如 c"Rust" 等价于 b"Rust\0"，这是向 C 侧传递字面量的便捷方式。

Nullability：C 的"任何指针都可能是 null"与 Option<NonNull<T>>

差异本质

Rust 通过 Option<T> 在类型层面显式表达可空性，编译器强制调用方在解引用前处理空值；而 C 中任何指针都可能为 null，没有任何类型系统层面的提示。

边界处的后果

课程 <details> 备注指出：从 C 收到的每一个指针都必须检查，才能创建 Option<NonNull<T>>——这意味着要么编写 unsafe 块做检查，要么承担运行时开销。换句话说，Rust 侧想把"可能为空的裸指针"安全地包装成"可空引用"，必须自己手动完成 C 侧缺失的空值检查，无法直接依赖类型系统。

这与 type-safety.md 一节的"类型安全考量"一脉相承：跨边界时 Rust 的类型保证会退化，需要开发者用代码重新建立不变量。一个常见的模式是：在边界处立即将裸指针转换为 Option<&T> 或 Option<NonNull<T>>，让空值检查在进入 Rust 世界的第一时间完成，之后在 Rust 内部不再接触裸指针。

Ownership：仿射类型、生命周期 vs "靠约定"

差异本质

Rust 的类型系统是仿射的（affine）：每个值恰好被使用一次，配合所有权与生命周期规则，编译器能静态保证没有悬垂引用、没有重复释放；而 C 的内存管理完全靠约定——谁分配、谁释放、缓冲区存活多久，都写在注释和文档里，靠人遵守。

边界处的后果

课程 <details> 备注只有一句话，却分量极重：必须手动记录并强制执行对象生命周期（Must document and enforce object lifetimes manually）。跨过 FFI 边界后：

• Rust 编译器无法看到 C 侧谁在引用这块内存；
• C 侧也无法感知 Rust 的所有权转移语义（move、Drop 等）；
• 因此，*_create() / *_destroy() 这类成对的分配释放函数必须显式暴露，并在 Rust 侧用 RAII 包装（例如用实现 Drop 的 struct 包裹 C 句柄），把 C 的"约定式所有权"重新翻译回 Rust 的类型安全世界。

仓库佐证：生命周期无法表达的 C 语义

配套讲义 semantics.md 给出了一个极佳的例子——C 标准库的 ctime 函数：

use std::ffi::{CStr, c_char};
use std::time::{SystemTime, SystemTimeError, UNIX_EPOCH};

unsafe extern "C" {
    /// Create a formatted time based on timestamp `t`.
    fn ctime(t: *const libc::time_t) -> *const c_char;
}

fn now_formatted() -> Result<String, SystemTimeError> {
    let now = SystemTime::now().duration_since(UNIX_EPOCH)?;
    let seconds = now.as_secs() as i64;

    // SAFETY: `seconds` is generated by the system clock and will not cause
    // overflow
    let ptr = unsafe { ctime(&seconds) };

    // SAFETY: ctime returns a pointer to a preallocated (non-null) buffer
    let ptr = unsafe { CStr::from_ptr(ptr) };

    // SAFETY: ctime uses valid UTF-8
    let fmt = ptr.to_str().unwrap();

    Ok(fmt.trim_end().to_string())
}

ctime 修改的是多次调用之间共享的内部缓冲区——下一次调用会覆盖上一次的结果。讲义指出，这种语义无法用 Rust 的生命周期表示：

• 'static 不适用，因为语义不同（缓冲区不是真正"永久存活"）；
• 某个具体生命周期 'a 也不适用，因为缓冲区比单次调用存活得更久（其生命周期横跨多次调用）。

这个例子的深刻之处在于：它不是"写代码时小心一点"就能绕过的表面问题，而是Rust 的类型系统从根本上就无法表达这种共享可变全局缓冲区的生命周期。这类 C 语义在穿过边界时只能靠人的纪律与注释来维持。这正呼应了 semantics.md 开篇的论断："其他语言允许的某些构造，在 Rust 语言中根本无法表达。"

Callbacks：闭包 vs 函数指针 + void* userdata

差异本质

Rust 的回调通常用 Fn/FnMut/FnOnce 闭包表达，可以捕获环境、类型安全地传递；而 C 的回调只有函数指针这一种形态，若要携带上下文，只能额外附加一个 void* userdata 指针。

边界处的后果

课程 <details> 备注指出两点：

1. 必须把闭包分解为 fn pointer + context：Rust 闭包默认是匿名类型，无法直接作为 C 函数指针使用，必须拆成"一个不捕获任何东西的普通函数 + 一个承载捕获状态的环境指针"，再通过 C 约定的 void* userdata 机制把环境传回。
2. context 的生命周期是手动管理的：void* userdata 指向的捕获数据存活多久、由谁释放，都需要在边界两侧显式约定，Rust 编译器在这里帮不上忙——这是所有权差异（见上一节）在回调场景的具体体现。

一个典型的安全封装模式是：在 Rust 侧把闭包 Box 起来，将 Box 的裸指针作为 userdata 传给 C；C 调用回调时把 userdata 原样传回；Rust 侧再把裸指针还原为 Box 取回闭包。整个过程需要严格保证 C 侧不会在闭包生命周期之外调用回调，否则就是悬垂指针。

Panics：栈展开 vs abort——跨边界 panic 是未定义行为

差异本质

Rust 默认的 panic 策略是栈展开（stack unwinding）：沿着调用栈向上回退，沿途执行析构（Drop），直到程序退出或被捕获；也可以配置为 panic = 'abort' 直接终止进程。而 C 没有异常机制，遇到致命错误只能 abort。

边界处的后果

课程 <details> 备注给出了一条硬性规则：panic 跨过 FFI 边界是未定义行为（undefined behavior）；必须在边界处用 catch_unwind 捕获。

为什么是未定义行为？因为 C 编译器生成的代码不知道 Rust 的栈展开机制，也不会为 Rust 的 Drop 析构运行清理代码。如果一个 Rust 函数通过 extern "C" 导出给 C，却在内部 panic 并向 C 的调用栈展开，就会破坏 C 栈的不变量，导致内存损坏甚至崩溃。

仓库佐证：catch_unwind 的正确使用

仓库的 Panics 讲义 详细讲解了捕获机制：

use std::panic;

fn main() {
    let result = panic::catch_unwind(|| "No problem here!");
    dbg!(result);

    let result = panic::catch_unwind(|| {
        panic!("oh no!");
    });
    dbg!(result);
}

catch_unwind 返回 Result：没有 panic 时是 Ok(闭包返回值)，发生 panic 时是 Err(panic 载荷)。讲义同时给出了三条重要边界条件，对 FFI 场景尤为关键：

1. 捕获是反常操作，不要试图用 catch_unwind 实现异常机制——它只应在"服务器需要保持运行"这类极少数场景使用；
2. 如果 Cargo.toml 中设置了 panic = 'abort'，catch_unwind 将不再生效——此时任何 panic 都会直接终止进程，因此凡是有 C 调用方的导出函数，更要在边界内确保绝不 panic；
3. Panic 是"不可恢复的意外错误"的信号，是程序 bug 的症状——边界处捕获它，是为了把"崩溃"降级为"返回错误码给 C 侧"，而不是把它当作正常的错误流。

因此，在 FFI 边界函数中的典型写法是：把整个函数体包进 catch_unwind，捕获到 Err 时返回 C 约定的错误码，让 panic 永远不越过边界。

从差异到实践：安全 FFI 边界的四条铁律

综合以上六大差异，并结合仓库中 FFI 章节 README（"先从包装一个简单的 C 函数开始，再深入到涉及指针与未初始化内存的复杂情况"）与 abs.md 给出的包装模式，可以提炼出设计安全 FFI 边界的四条铁律：

1. 先定义签名，再决定安全性。 abs.md 给出了包装 C 函数的标准流程：先找到外部函数签名的权威定义（如 man 3 abs 中的 int abs(int j);），在 unsafe extern "C" 块中写出匹配的 Rust 签名，确认需要维护的安全不变量，再决定能否把函数标记为 safe。其中有两个细节值得注意：

• 使用 std::ffi::c_int 而非硬编码 i32 可以提升可移植性——根据 C 标准，c_int 在理论上可能是 i16 而不是常见的 i32，交由标准库按目标平台确定宽度更稳妥；
• 对于确认无副作用、调用方无法破坏内存安全不变量的函数，可以用 safe fn 标记，使其无需 unsafe 块即可调用：

use std::ffi::c_int;

unsafe extern "C" {
    safe fn abs(x: c_int) -> c_int;
}

fn main() {
    let x = -42;
    let abs_x = abs(x);
    println!("{x}, {abs_x}");
}

2. 边界处完成全部"翻译"： 错误转成 C 约定的错误码、裸指针第一时间做 null 检查并包装成 Option<NonNull<T>>、char* 做 UTF-8 验证后转 &str、闭包拆成 fn pointer + userdata——所有差异翻译都集中在边界薄薄一层完成，边界之内只使用纯 Rust 类型。

3. 用 RAII 重新建立所有权约定： 用实现 Drop 的 Rust 结构包装 C 句柄（*_destroy() 写在 Drop::drop 里），把 C 的"约定式所有权"升级为编译器强制的资源管理。

4. panic 绝不越界： 导出函数整体用 catch_unwind 包裹，配合 panic = 'abort' 的配置检查，确保 C 调用方看到的只有错误码，没有未定义行为。

延伸阅读：完整的语言差异地图

本文聚焦 Rust ↔ C 的差异，而 comprehensive-rust 的 language-differences 目录 还包含另外两张对照表，可帮助你构建完整的语言差异地图：

• representations.md：三种语言对同一份数据的表示差异（空终止、长度前缀、Rust 字节切片）；
• semantics.md：C 语义（如 ctime 的共享缓冲区）无法被 Rust 生命周期表达的根本性冲突；
• cpp-and-c.md：C++ ↔ C 的差异（重载的名字修饰、异常必须转错误码、析构函数必须显式 *_destroy()、非 POD 类型只能不透明指针、模板必须显式实例化包装）——由于 C 是"最低公共分母"，这些差异同样会在 Rust 间接调用 C++ 时浮现。

如果你希望进一步验证本文提到的各项差异在真实代码中的形态，可以继续阅读仓库中 FFI 章节 下的 abs.md（C 函数包装全流程）、c-library-example.md（完整 C 库互操作示例）与 type-safety.md（边界类型安全考量）。掌握"六大差异 + 四条铁律"之后，你就能在 Rust 与 C 之间设计出既安全又高效的互操作层。