如果你手头有一个运行了好几年的 C 代码库突然团队里有人提议新模块别用 C 了改成 Rust 吧你第一反应大概率是想拒绝——重写是不可能重写的这辈子都不可能重写的。但现实是越来越多的项目确实开始在 C 和 Rust 之间做混合编程老代码不用动新的内存安全敏感模块用 Rust 写然后两边通过 FFI 互相调用。我最初接触 C 与 Rust 交互编程就是出于这个需求为了把一个运行多年、核心逻辑庞大无法整体改写的 C 系统逐步将高风险模块替换为 Rust 实现同时保持对外接口不变。这个方案的好处很明显不用推倒重来还能让 Rust 在边界内管理好自己那一亩三分地的内存安全。这篇文章不是教科书是我在实际工程里折腾 C 与 Rust 交互编程的完整记录。从 ABI 原理、构建系统集成、跨边界内存管理到回调、异常、异步这些复杂场景的落地姿势再到我踩过的几个很隐蔽的坑都会拆开讲清楚。无论你是打算在存量 C 项目里引入 Rust还是想搞清楚到底怎么让两种语言在一个进程里和平共处这篇文章应该能帮你省下不少试错时间。1. 为什么非要把 C 和 Rust 揉在一起真实取舍与适用场景1.1 在不推翻老代码的前提下获得内存安全先说动机。一个 C 项目想用 Rust几乎都不是因为Rust 很酷而是看中了它的内存安全和无数据竞争保证。当代码库到了几十万行甚至上百万行的时候C 智能指针和代码规范能解决大部分问题但总有一些角落——比如裸指针管理缓冲区的网络层、跨线程共享状态的模块——是事故高发区。把这些模块用 Rust 重写后通过 FFI 暴露给 C 调用是最划算的做法老系统对外行为保持不变内部实现换了引擎风险被关在 Rust 的沙盒里。另一个常见场景是插件系统。宿主程序用 C 写插件想用 Rust 写。插件和宿主之间只需要约定一个稳定的 C 接口两边各自编译成动态库就能完全解耦。我见过不少项目组就是靠这套办法让熟悉 Rust 的团队能独立交付模块不必等 C 主流程的发布节奏。1.2 什么情况不适合做 C/Rust 交互并不是所有项目都适合混着写。如果你的边界很薄比如只是调几个数学函数那折腾 FFI 的收益就很低又或者你的核心代码是大量模板元编程和复杂继承体系把它们暴露到 FFI 边界会非常痛苦。交互编程有一个隐含成本跨边界的调用不再是普通的 C 函数调用不能传递类和引用不能抛异常每一步都要精心设计接口。还有团队因素。如果团队里没人熟悉 Rust也没有意愿去学硬上混合架构大概率会演变成两边互相看不懂对方代码的灾难。至少得有一个人能同时 hold 住两个语言的 ABI 细节和构建流程否则出了问题无从下手。1.3 渐进式改造的落地节奏我比较推荐的做法是先划边界再立接口最后替换实现。具体来说先把要废弃的 C 模块对外暴露的接口整理成纯 C 风格函数、结构体、不透明句柄然后用 Rust 实现同名的 extern C 函数编译成静态库或动态库在 CMake 层把链接目标切换过去。C 侧接口不变调用方代码一行都不用改。这里有个经验不要一开始就想做整库替换先挑一个边界清晰、功能独立的小模块走通全流程比如读取配置文件、计算校验值这类无状态逻辑。第一次跑通后团队就能积累出一套自己的交互模式后面再扩展就顺了。判定维度适合混合编程不适合混合编程模块边界清晰、可抽象为 C 函数与 C 模板/继承深度耦合替换目的安全敏感/易出 bug 模块只是图省事重写团队能力有一名以上 Rust 熟练成员全员零 Rust 基础边界频率低频大块调用高频细粒度逻辑存量代码百万行无法整体重写小项目可直接整体迁移2. FFI 边界的地基C ABI 是唯一通用语言2.1 C 的 ABI 为什么不能直接和 Rust 互相调用很多人第一次做混编会想当然C 能调 CRust 也能调 C那 C 直接调 Rust 应该也行吧这个行的关键在于大家都往 C ABI 上靠。C 之所以不能直接和 Rust 互通是因为 C ABI 包含大量语言专属约定名字修饰name mangling、异常展开信息、this 指针传递方式、虚表布局等。每个编译器甚至不同版本都可能不一样Rust 根本没有义务去理解这些。名字修饰就是个典型的拦路虎。C 函数int add(int a, int b)在符号表里实际叫_Z3addii这样的修饰名Rust 按自己的规则生成符号两边对不上链接器直接报 undefined reference。解决办法就是统一用 C ABI 作为中间层Rust 用#[no_mangle]关掉符号修饰用extern C指定调用约定C 侧用extern C包裹声明让编译器按 C 规则生成符号。2.2 extern C 和 #[no_mangle] 的配合逻辑在 Rust 侧一段能被 C 调用的函数长这样#[no_mangle] pub extern C fn rust_add(a: i32, b: i32) - i32 { a b }extern C告诉编译器使用 C 调用约定参数从右到左入栈、由调用者清理栈等#[no_mangle]保证导出的符号就是函数名本身不会变成带哈希后缀的修饰名。C 侧对应的声明extern C { int rust_add(int a, int b); }这段代码写在头文件里告诉 C 编译器rust_add这个名字已经在别处以 C 符号规则编译好了你链接的时候直接找这个符号就行。注意别在 C 侧给这个函数加static否则符号就变成内部的了。2.3 repr(C) 与结构体布局对齐函数能互通了数据怎么传结构体是最容易出问题的地方。Rust 默认的结构体字段顺序是未指定的编译器可能为了优化重新排布C 和 C 则严格按声明顺序排列并在特定位置插入填充字节以满足对齐。如果直接把两边结构体简单对齐轻则读错字段重则内存越界。解决办法是在 Rust 结构体上标注#[repr(C)]#[repr(C)] pub struct Config { pub version: u32, pub flags: u8, pub reserved: [u8; 3], }加上#[repr(C)]后Rust 会按照 C 语言的布局规则排列字段。这样两边拿到的内存视图是一致的。这里建议你自己手动补齐填充字段而不是依赖编译器隐式插入——显式字段让两份代码一眼望去就对得上排查布局问题时会轻松很多。2.4 cbindgen自动生成 C 头文件手写 C 头文件来匹配 Rust 结构体小项目没问题结构体一多就累死人还容易两边改不同步。业界通用的做法是让 Rust 侧作为单一事实来源用 cbindgen 根据 Rust 源码自动生成 C 头文件cbindgen --lang c --output include/rust_bridge.h src/lib.rscbindgen 会解析 Rust 里extern C导出的函数和#[repr(C)]的结构体生成对应的 C 声明。这样你只需要在 Rust 侧维护一套定义C 头文件是产物想不一致都难。实测下来凡是结构体字段比较多、函数导出比较频繁的项目必须上 cbindgen手写不仅效率低错误率还高。3. C 调用 Rust从编写库到链接的完整链路3.1 第一步把 Rust 核心逻辑包成 extern C 函数假设我们要把一段字符串处理逻辑用 Rust 重写。先写核心 Rust 实现不涉及 FFI 的纯逻辑pub fn sanitize(input: str) - String { input.chars().filter(|c| !c.is_ascii_control()).collect() }这个函数要用到字符串而 C 边界上没有String和str这种类型。跨边界传字符串的标准做法是用 C 字符串Rust 接收*const c_char先转成str处理完再转回 C 字符串返回。完整的 FFI 层封装use std::ffi::{CStr, CString}; use std::os::raw::c_char; #[no_mangle] pub extern C fn sanitize_input(input: *const c_char) - *mut c_char { if input.is_null() { return std::ptr::null_mut(); } let input_str unsafe { CStr::from_ptr(input) }.to_string_lossy(); let result sanitize(input_str); // 这里的内存由 Rust 分配返回给 C 后必须由 Rust 负责释放 CString::new(result).ok().map(|s| s.into_raw()).unwrap_or(std::ptr::null_mut()) }注意返回的是*mut c_char这是一种借用给 C 的指针内存仍然由 Rust 管理。后面会专门讲为什么这种设计常常是坑。3.2 第二步构建静态库并暴露头文件在 Cargo.toml 里确认 crate 类型是 staticlib 或 cdylib[lib] name rust_core crate-type [staticlib]staticlib会生成.a文件适合链接进 C 的可执行文件cdylib生成动态库。用 cbindgen 生成头文件后C 侧就能写调用了#include string #include rust_bridge.h std::string safe_clean(const std::string raw) { char* cleaned sanitize_input(raw.c_str()); if (!cleaned) return ; std::string result(cleaned); rust_free_string(cleaned); // 必须调用 Rust 提供的释放函数 return result; }这里的关键点C 拿到char*后用完必须调用 Rust 侧提供的释放函数比如rust_free_string绝对不能直接free或delete。因为这块内存是 Rust 的分配器分配的C 运行时不知道该怎么释放它。谁分配、谁释放这条铁律在跨语言边界上从不出错。3.3 第三步CMake 与 Cargo 的集成构建时把 Rust 静态库链接进 C 可执行文件最省事的方法是在 CMake 里先调用 cargo 编译再 target_link_libraries。一个稳妥的 CMake 片段add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/librust_core.a COMMAND cargo build --release --target-dir ${CMAKE_CURRENT_BINARY_DIR} WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/rust_core DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/rust_core/src/lib.rs ) add_library(rust_core STATIC IMPORTED) set_target_properties(rust_core PROPERTIES IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/librust_core.a ) target_link_libraries(your_app PRIVATE rust_core)这两段代码看起来简单但实际工程里构建顺序、增量编译、依赖传递都要慢慢打磨。不过方向对了后面只是细节问题。3.4 调用示例与验证写一个简单的 C 测试程序链接编译运行g -stdc17 main.cpp rust_bridge.h -L. -lrust_core -lpthread -ldl -lm -o demoRust 静态库会额外引入一些系统库依赖不同平台要补的库不一样最稳妥的做法是把错误信息里的缺失符号当作线索逐个补上。我第一次编译时忘了加-lpthread链接器报了一堆pthread_createundefined加上就好了。4. Rust 调用 C绑定生成与手工封装4.1 最小可行的 extern 块声明Rust 调用 C本质是把 C 编译成带 C ABI 符号的库然后在 Rust 侧声明这些符号。最直接的方式是手写extern块extern C { fn cpp_compute_hash(data: *const u8, len: usize) - u64; }这里cpp_compute_hash是 C 侧用extern C导出的函数。Rust 侧声明它就等于告诉链接器这个符号存在类型长这样编译时不校验链接时才找。4.2 C 对象跨边界不透明指针的核心技巧C 的类和 Rust 的结构体模型完全不同跨边界传对象只有一个现实方案不透明指针。C 侧把对象封装成一个不透明句柄Rust 侧只保存这个指针从不访问其内部extern C { void* session_create(); void session_destroy(void* session); int session_process(void* session, const char* input); }Rust 侧把void*看作一个不透明的*mut c_void封装成一个生命周期明确的 wrapper structpub struct Session { raw: *mut c_void, } impl Session { pub fn new() - Self { Session { raw: unsafe { session_create() } } } pub fn process(self, input: str) - i32 { let c_input CString::new(input).unwrap(); unsafe { session_process(self.raw, c_input.as_ptr()) } } } impl Drop for Session { fn drop(mut self) { unsafe { session_destroy(self.raw) }; } }注意Session本身不能跨 FFI 传回 C它的职责就是把裸指针包装成安全 Rust API。Drop的实现保证了 C 对象的析构函数会被正确调用这就是Rust 侧管理生命周期C 侧管理实际内存的典型分工。4.3 bindgen批量生成绑定的正确用法手写 extern 块适合函数少的场景遇到几百个头文件的项目就废了。业界标准方案是 bindgen它读取 C/C 头文件自动生成 Rust 绑定代码bindgen --allowlist-function cpp_compute_hash \ --allowlist-type MyConfig.* \ --no-debug .* \ -o bindings.rs cpp_bridge.h需要注意--allowlist参数指定只生成为我们准备好的头文件里的这些类型。默认生成所有内容包括系统头文件的东西会导致绑定包含大量无用的stddef.h等类型定义编译又慢又容易出错。bindgen 生成的绑定可以直接include!进 Rust 源码。4.4 C 类方法的包装策略bindgen 能生成类的绑定但用起来很别扭——它会把类转成 Rust 的不透明结构体方法生成一堆包含this指针的 free function。更实际的做法是不让 bindgen 处理复杂类只暴露一个手写的 C 风格 wrapper。C 侧写一层薄薄的胶水代码extern C { void* session_create() { return new MySession(); } void session_destroy(void* s) { delete static_castMySession*(s); } int session_process(void* s, const char* input) { return static_castMySession*(s)-process(input); } }这层胶水代码虽然机械但它把 C 内部的复杂度全部隔离在边界另一侧。Rust 永远不需要知道MySession里有什么成员、继承链多长、有没有虚函数它只需要跟void*打交道。这是我最推荐的跨边界封装方式。绑定方案适用场景维护成本风险点手写 extern 块函数少、类型简单低签名不一致难发现bindgen 全自动生成头文件量大、类型规范中类型布局依赖编译器选项C 手写 C wrapper Rust 包装复杂类、继承体系中高需维护两遍胶水代码5. 跨边界内存与所有权规则谁分配谁释放5.1 铁律内存分配和释放必须停留在同一侧跨语言边界的头号杀手就是内存释放错位。C 的new/delete和 Rust 的分配器是两套体系互相对调就是非法内存操作。我定下的边界协议是函数返回什么指针同侧必须提供释放函数。之前那节里sanitize_input返回*mut c_char那就要配套导出#[no_mangle] pub extern C fn rust_free_string(ptr: *mut c_char) { if !ptr.is_null() { unsafe { drop(CString::from_raw(ptr)) }; } }C 侧所有拿到 Rust 返回字符串的地方收尾时唯一合法操作就是调用rust_free_string。哪怕你看着char*就是裸内存也必须忍住手别去free。5.2 Rust 的 Box 与裸指针交接跨边界传递 Rust 堆上对象时常用Box::into_raw把所有权转移出去再用Box::from_raw收回来。这套机制是安全的因为它保证对象不会被提前析构#[no_mangle] pub extern C fn data_create(value: i64) - *mut Data { Box::into_raw(Box::new(Data { value })) } #[no_mangle] pub extern C fn data_get_value(ptr: *const Data) - i64 { if ptr.is_null() { return 0; } unsafe { (*ptr).value } } #[no_mangle] pub extern C fn data_destroy(ptr: *mut Data) { if !ptr.is_null() { unsafe { drop(Box::from_raw(ptr)); } } }Box::into_raw保留了堆内存但放弃析构责任Box::from_raw重新接管所有权它一被 drop对象就正常释放。整个过程里 C 侧只是临时保管指针没有触碰底层内存这样安全性和可控性兼顾。5.3 生命周期标注在 FFI 边界上只是文档Rust 内部的生命周期系统在跨 FFI 时不生效。你在extern C函数签名里写a是做不到的C ABI 的指针参数根本不携带生命周期信息。这意味着跨边界传递指针时编译器不再保护你唯一的防护是边界两侧的人在编程时心里有一把尺。这把尺就是约定跨边界传入的裸指针只在函数调用期间有效。如果你需要跨多次调用保存指针比如不透明句柄你要把句柄的创建与销毁成对出现作为接口的硬性契约并在 C 侧用 RAII 封装裸指针确保异常路径上也会调用销毁函数。5.4 数组与容器的交接跨边界传数组要同时传长度和指针。C 的std::vector内部缓冲区不能直接暴露给 Rust 当作 slice 用因为布局没有保证。Rust 侧接收数组的标准姿势#[no_mangle] pub extern C fn sum_array(ptr: *const i32, len: usize) - i64 { if ptr.is_null() || len 0 { return 0; } let slice unsafe { std::slice::from_raw_parts(ptr, len) }; slice.iter().map(|x| x as i64).sum() }关键约束from_raw_parts的len必须与 C 侧实际分配的元素个数一致多传一个字节都可能越界读取。建议在 Rust 侧把长度校验做成 debug assertion调试阶段能抓出一大批错误。6. 回调、异常与异步跨语言边界的复杂姿势6.1 把 Rust 回调传给 C函数指针与裸指针捕获C 侧常常需要 Rust 侧提供回调比如日志回调、进度回调。回调跨边界的本质是把一个extern C fn函数指针传给 C再配一个不透明上下文指针让 C 回传pub type Callback extern C fn(ctx: *mut c_void, data: *const c_char); #[no_mangle] pub extern C fn rust_callback(ctx: *mut c_void, data: *const c_char) { if data.is_null() { return; } let msg unsafe { CStr::from_ptr(data) }.to_string_lossy(); // 从 ctx 还原 Rust 包装对象 unsafe { (*(ctx as *mut CallbackContext)).handle(msg); } }注意回调函数必须是extern C fn不能是 Rust 闭包。闭包会捕获环境而 C ABI 不支持闭包对象。变通方案是把闭包偷渡成一个Boxdyn Fn对象用裸指针传进去#[no_mangle] pub extern C fn register_callback( ctx: *mut c_void, cb: extern C fn(*mut c_void, *const c_char), ) { unsafe { cpp_register_callback(ctx, cb); } }实际使用时我会定义一个 Rust 侧全局管理HashMapu64, Boxdyn Fn(str)C 回调携带一个整数 ID 进来Rust 侧查表后调用真正的闭包。这样绕开函数指针无法捕获环境的限制但要注意全局状态要处理并发和生命周期。6.2 异常不能穿越边界C 异常和 Rust panic 的边界处置这条必须提前刻在脑子里两边各有一套倒腾错误的机制但是都不能直接穿越 C ABI 边界。C 里抛异常穿越 extern C 函数轻则 UB重则直接崩溃。因此 C 侧导出给 Rust 的函数必须用 try/catch 包裹所有逻辑extern C { int cpp_divide(int a, int b) { try { if (b 0) throw std::runtime_error(divide by zero); return a / b; } catch (...) { return -1; // 错误码跨边界 } } }Rust 侧同理extern C函数内部绝不能直接 panic。#[no_mangle] pub extern C函数一旦 panic 并跨过边界C 侧是无法接住的结果是 abort。标准做法是在每个边界的 Rust 函数入口加catch_unwind#[no_mangle] pub extern C fn rust_divide(a: i32, b: i32) - i32 { match std::panic::catch_unwind(|| a / b) { Ok(v) v, Err(_) -1, } }6.3 异步模型两边 async 的桥接思路C 的std::async、Boost.Asio、Qt 的信号槽和 Rust 的tokio/async-std在底层调度模型上完全不同。试图让一个 Rust async 函数直接出现在 C 调用栈上是一件让人失眠的事。我的建议是异步在边界两侧内部各自消化跨边界暴露同步接口。Rust 侧如果核心用了 async那就用tokio::main在某个初始化函数里启动 runtime对外提供的 FFI 函数用block_on同步等待。C 侧如果要保持异步就自己开线程去调 Rust 的同步函数。这样边界上是阻塞调用逻辑简单、不出幺蛾子。6.4 错误码 vs 错误对象的取舍跨边界错误处理应当尽量简单。C 异常不能穿墙RustResult也不能直接映射成 C 异常。统一用错误码或错误对象指针。简单场景用枚举错误码#[repr(C)] pub enum ErrorCode { Ok 0, NullPointer 1, InvalidInput 2, InternalError 3, }复杂场景可以让函数返回错误码 通过输出参数返回错误信息字符串配合之前的释放接口来清理。7. 构建系统集成CMake 与 Cargo 的协作方式7.1 三种常见的集成模式对比工程落地的最后一步就是让两个语言的构建系统不再各自为政。我试过三种主流方式集成模式操作方式优点缺点CMake 调 CargoCMake 里执行 cargo build再链接产物增量构建清晰CMake 与 Cargo 版本耦合Cargo 调 CMakeRust crate 的 build.rs 里执行 cmake统一在 cargo 侧管理C 项目被迫迁入 cargo 工作区独立构建统一发布CI 里分两步构建再合并两边完全独立开发期同步麻烦我在大多数项目中用第一种C 项目保持 CMake 为主Rust 作为外来模块被 CMake 编译。原因很简单存量的 C 工程体系和 CI 都围绕 CMake 搭建Rust 这边只要把自己的产物交给 CMake 就好侵入最小。7.2 静态库链接顺序的玄学链接 C 和 Rust 静态库时链接器对静态库的顺序有要求。如果用 GNU 链接器-l参数顺序与被引用关系有关。Rust 静态库常常依赖一堆系统库而且 Rust 库内部符号间也有依赖。我的经验是把 Rust 库放在 C 库之后后面再补系统库target_link_libraries(app PRIVATE your_cpp_lib rust_core pthread dl m )如果回去看到 undefined reference但对应符号确实在该库中就去调整顺序。链接器从左到右扫描靠右的库需要满足左边产生的未定义符号rust_core要放在your_cpp_lib右边。7.3 Windows 平台的特殊事项Windows 上把 Rust 编译成动态库时记得#[no_mangle] pub extern C之外还要显式处理导出表。Rust 的 cdylib 默认会把 no_mangle 符号导出但有时候需要规避 stdcall 与 cdecl 的混淆——历史原因让 Windows 上有两套 C 调用约定现代 64 位系统统一了但 32 位工程还要注意。还有dllimport/dllexport的问题Rust 动态库的导出符号 C 侧可以直接extern C引用C 侧导出给 Rust 用则要在编译时加__declspec(dllexport)。Windows 调试符号建议把“最终命令行”里的参数保存下来 VS 和 MinGW 混用时符号处理差异很大尽量统一工具链8. 实测中踩过的坑与排查思路8.1 结构体布局不一致看起来对、读起来错一次在项目里传一个包含 bool 和指针的结构体C 侧读出来的字段偶尔错乱。排查半天最后发现 Rust 侧忘了加#[repr(C)]编译器把字段顺序打乱了。这是混编最常见的坑也是最难定位的一类——因为错误不是必现只在某些数据组合下表现出来。从那以后我给自己立了规矩涉及跨边界的所有结构体直接在定义上方写注释标清每个字段和 C 侧的对应关系。排查这类问题最直接的手段是打印内存偏移Rust 侧用std::mem::offset_of!或者 sizeofC 侧用offsetof宏两边对比数值。如果偏移一致再逐个字段做边界读写测试。8.2 panic 穿越边界的诡异崩溃Rust 侧在 extern C 函数里写了个 unwrap输入数据不合预期时 panic没有 catch_unwind 兜底C 调用方看到的直接是 abort连错误码都没有。这个问题之所以严重是因为 panic 跨边界本身就是 UB崩溃现场还常常不在代码出错的位置而是在 C 栈展开的某个奇怪的地方。记录一个实际的表象C 侧错误处理了返回值 -1 就继续跑结果崩在完全无关的函数里。从排查角度看首先要检查所有边界函数有没有 panic 风险统一封装catch_unwind并写进代码评审的检查清单。宁可在边界上吞掉异常信息返回错误码也比 abort 好。8.3 双重释放与悬垂指针明明遵守了规则有一次我们遵守了谁分配谁释放却仍然发生了双重释放。后来发现原因在 C 侧两个不同模块从 Rust 获取了同一个char*指针因为 Rust 侧用了全局缓存返回同一块内存各自释放了一遍。这告诉我们跨边界的接口文档必须写清楚返回的指针是否具有唯一所有权。如果要返回同一份数据应该让 Rust 每次新建内存并把所有权交出去或者采用引用计数。还有一个容易引发悬垂指针的操作把跨边界指针存进static全局变量。Rust 侧持有一个static mut指向 C 堆对象C 侧销毁对象后忘记通知 Rust 侧Rust 侧再次访问就悬垂了。处理方案很简单但也啰嗦所有跨边界指针必须规定严格的缓存/释放协议别让全局状态悄悄存指针。8.4 符号冲突两边都有同名函数一次把 Rust 静态库和另一个第三方 C 库一起链接两边都导出了process符号结果链接器选用了一个实现行为完全错误。排查这个问题的思路是查符号表。Linux 下用nm查看哪些符号有多个定义再用objdump -T看动态库导出。链接器对重复符号不一定报错因为有很多文件允许符号覆盖这正是隐蔽性所在。预防措施给所有跨边界的导出函数加上清晰的项目前缀比如proj_rust_、proj_cpp_。这不是为了好看是以极低成本隔离符号空间值得写进团队规范。8.5 优化级别不同导致的诡异差异Rust 全部开 release 优化C 用 debug 编译某些交互逻辑在 debug 下没问题换到 release 就翻车。这通常不是两种语言的问题而是未定义行为被优化器放大了。典型的比如跨边界读取越界一个字节、std::slice::from_raw_parts长度多传了一个元素这些在 debug 构建里往往碰巧没事优化后的指令重排就让隐患爆发。我的排查步骤是先用安全消毒工具跑一遍边界比较 release 与 debug 行为差异再检查所有from_raw_parts、CStr::from_ptr的输入合法性。把边界当成最危险的地带去审查往往能先于用户发现问题。8.6 建一个跨边界的回归测试集最后一点经验针对每个边界函数建一个独立的回归测试脚本从两边各调一次验证返回值一致。测试要覆盖空指针、空字符串、长度为零的数组、超大数这些极端输入。我们项目里这份测试脚本后来立功很多次每次重构边界代码都是它最先抓到不兼容。尾声几个值得早点想明白的原则C 与 Rust 交互编程技术细节很多但底层的设计原则其实是有限的。按我现在的习惯拿到一个新的混编任务会先想清楚三件事第一边界要薄跨边界传递的大块数据能一次传就不要分十次第二边界要干净不要试图在边界上传 C 模板类型或 Rust 泛型高级抽象第三边界的错误处理要简单错误码优于异常也优于 panic。这些原则听起来很朴素但大多数崩溃现场最终复盘时都能归结到某一条没守住。另有一个值得养成的习惯在 Rust 侧统一写一份ffi.rs集中管理所有 extern C 导出函数和 cbindgen 配置别让 FFI 声明散落得到处都是。一份边界文件配上一个自动生成的头文件加上一组跨语言回归测试这套组合能让你在持续演进中保持清醒。C 与 Rust 交互编程的方案远不是能跑就行那么简单它需要纪律但回报是一套可以长期维护的混合架构——老系统继续稳定运行新代码却换上了更安全的引擎。
