两个项目文件结构一比，差别就出来了。C/C++项目拿到手里，先是CMakeLists.txt，然后是src、include、tests这些目录，各人习惯不同但大差不差。Rust项目则规范得多，cargo new一下，目录骨架就给你搭好了，源文件放src，配置文件Cargo.toml，第三方依赖统一管。
构建流程的差异更明显。C/C++项目里，CMake生成makefile，然后make，然后make install，中间还可能冒出几个警告，链接阶段再来个"undefined reference"，折腾半天。Rust这边一个cargo build就完了，下载依赖、编译、链接全自动，编译错误信息还会提示你该怎么改。
但项目结构的差异只是表面，真正让两个生态分道扬镳的，是内存管理、错误处理、并发模型、构建系统这些底层设计的选择。甚至当你想让C/C++和Rust互通时，还得面对ABI兼容、指针所有权交接这些头疼问题。
这篇文章我会结合自己实际写C++服务端和Rust CLI工具的经历，把两种项目从组织方式、核心语言特性、并发编程、互操作到调试部署的差异摊开来讲。尤其会重点聊聊Rust的所有权系统、借用检查、生命周期这三个最劝退也最核心的概念，以及C/C++开发者迁移到Rust时最容易踩的坑。
1. 项目组织与构建系统
1.1 C/C++项目的建置逻辑
C/C++项目建置向来是个"自由又混乱"的领域。传统Makefile自由度极高，你可以定义任意规则，但也意味着每个项目都有自己的一套写法。后来CMake出现，算是给C++世界带来了一个相对普及的建置工具，它不直接编译，而是生成对应平台的构建脚本，比如Unix/Linux下的Makefile，或者Windows下的Visual Studio工程。
我之前维护过一个C++的服务端项目，CMakeLists.txt里光是处理不同平台的宏定义、链接第三方库就有上百行。更要命的是依赖管理——C++生态至今没有一个像npm或pip那样统一的官方包管理器。你想用一个json解析库，要么把源码直接拷进来，要么用vcpkg、conan这类第三方管理器去拉取，但拉下来的版本可能和你本地环境不兼容，又得折腾编译选项。
C/C++项目的典型结构：
my_cpp_project/ ├── CMakeLists.txt ├── src/ │ ├── main.cpp │ ├── module_a.cpp │ └── module_b.cpp ├── include/ │ ├── module_a.h │ └── module_b.h └── third_party/ ├── json.hpp └── log.h编译过程分两步走：先编译出目标文件（.o或.obj），再把所有目标文件链接成最终可执行文件或库。当项目规模大了，增量编译依赖Make或Ninja的时间戳判断，有时改一个头文件导致大范围重编，让人直挠头。如果没配好预编译头或者没注意头文件的include次数，编译时间会指数级上升。
1.2 Rust项目的Cargo工作流
Rust一出生就坚定地走了另一条路，Cargo是它的构建系统和包管理器，地位等同于npm之于Node.js，或者说更准确，像Rust官方钦定的全家桶。你不需要针对不同平台写不同的构建脚本，Cargo会自动处理跨平台编译，并在同一个Cargo.toml里描述依赖、二进制目标、库目标、测试目标等。
[package] name = "my_rust_project" version = "0.1.0" edition = "2021" [dependencies] serde = { version = "1.0", features = ["derive"] } tokio = { version = "1", features = ["full"] }cargo new创建的项目天然区分src和tests目录，还能直接用cargo test跑单元测试，cargo fmt统一代码风格，cargo clippy做静态检查。这些在C/C++世界里往往要靠CI流水线额外配置，但在Rust项目里就是内置能力。
Rust项目对"依赖的确定性"格外重视，Cargo.lock文件会锁定每个依赖的精确版本。这是效率导向的项目和长期维护项目的工程化差距——C/C++项目要回溯某个依赖版本时往往得手动翻记录，而Rust项目直接看lock文件就一目了然。
值得一提的还有workspace机制。宏服务端项目常把多个crate放同一个workspace统一管理，共享一套依赖版本约束，同时保留各自独立编译的灵活性。C/C++项目里想做到同等粒度的模块划分，需要花很多精力去设计CMake的target依赖，Rust这边天生就是这种结构。
1.3 两者构建哲学的碰撞
构建系统的分歧直接影响了团队协作方式。C/C++项目新人入门第一周往往在配环境：装编译器、装CMake、装依赖库、处理操作系统差异。Rust项目则友好得多，装了rustup之后，一切都在用户目录下，项目拉下来cargo build就能跑，团队成员很少因为环境不一致而浪费大半天。
这也带出一个心态上的差异：C/C++开发者习惯"自己动手丰衣足食"，愿意花几天时间折腾构建脚本；Rust开发者则更倾向"用官方推荐的方式做事情"，把精力省下来放在业务逻辑和系统设计上。
2. 核心语言特性的对决
2.1 内存管理：手工vs所有权
这是C/C++和Rust最核心的差别，也是很多搜索"c/c++八股"的同学真正想搞清楚的东西。
C/C++内存管理靠开发者自己。你new了就要delete，malloc了就要free，如果不小心漏了，内存泄漏；如果不小心释放两次，undefined behavior；如果释放了还在用，悬垂指针，直接崩溃或者数据被莫名篡改。C++11之后引入了智能指针（shared_ptr、unique_ptr、weak_ptr），算是在语言层面给了工具，但它依然是可选的，你不遵守依然没问题，出了问题编译器不拦你。
Rust则把内存管理提升为编译器检查的核心规则，它的所有权系统规定：每个值只有一个所有者，离开作用域即被自动释放。你可以把一个值转移给别人（move），也可以借给别人用（borrow），但不可能同时有两份可变引用。
举个例子：
fn main() { let s = String::from("hello"); let s2 = s; // s的所有权移动到s2，s此后不可用 // println!("{}", s); // 借用检查器直接拒绝编译 }这段代码在C++里假如把一个对象赋给另一个对象，通常是拷贝语义（或者移动语义，取决于是否move），s依然活着。但在Rust里这就是一个所有者转移，一旦s2接管，s就被视为未初始化。这个规则一开始很反直觉，但长期看，它消除了整类与悬垂指针、重复释放相关的bug。
"借用"则是所有权的扩展，让函数能使用数据而不接管所有权：
fn print_len(s: &str) { println!("{}", s.len()); }调用方传&s进来，print_len只有只读访问权，函数返回后数据依然归原变量所有。如果想在函数里修改，就需要&mut可变借用。借用检查器保证两件事：同时只允许一个可变借用，或者同时允许多个只读借用；借用不能超过所有者本身的生命周期。
这就是为什么Rust代码里到处是&和&mut的原因。C++鼠标悬停在一个变量上看到类型是Foo*，而Rust里看到的往往是&Foo。
2.2 生命周期：编译器在帮你做静态证明
生命周期参数是Rust里割裂初学者和三分钟热度学习者的分水岭。如果你只是写写脚本级的小程序，编译器能省略生命周期的标注；可一旦涉及到自定义结构体持有引用，生命周期标注就逃不掉。
生命周期本质上是描述引用有效范围的标签。看这个经典例子：
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str { if x.len() > y.len() { x } else { y } }这里<'a>声明了一个生命周期参数，意思是传入的两个引用和返回值必须保持同一个生命周期。编译器依靠这个信息静态检查，保证返回的引用不会指向已经释放的数据。
C/C++开发者对这类问题的解法往往是约定"调用者保证指针有效"，一旦违反就是悬垂指针或者use-after-free。Rust则是编译器强制你在编译期就明确这些约束，做不到就编译失败。这种严格，恰恰是Rust宣称"安全系统编程"的底气所在。
生命周期标注不是运行时开销，纯粹是编译期类型检查的一部分，这也是为什么Rust能做到和C++相近的性能却拥有更好的内存安全。
2.3 错误处理的差异
C/C++的错误处理基本靠返回值约定和异常。C语言标准库函数返回-1或NULL，然后靠errno全局变量看具体错误码；C++用try/catch抛异常，如果没接住就会层层上抛直到terminate。异常机制的缺点是控制流不透明，中间层如果忘了处理异常，整个调用栈都会被拆掉。
Rust用Result枚举把错误当作普通值来传递：
fn parse_num(s: &str) -> Result<i32, std::num::ParseIntError> { s.parse::<i32>() } fn main() { let result = parse_num("42"); match result { Ok(n) => println!("数字是: {}", n), Err(e) => eprintln!("解析出错: {}", e), } }这种设计有两个直接好处：第一，函数签名里肉眼可见地标记了"可能出错"，调用者不会被意外异常打断；第二，错误处理逻辑可以组合，用?运算符把错误直接向上传播，代码写起来比层层判断返回值简洁太多。
C++20标准库引入了std::expected，某种程度上说明主流C++社区也认可这种"错误是值"的哲学，但它进入C++生态并被普遍接受还需要很长时间。
2.4 C++对C的扩充vs Rust的现代化特征
"c++对c的扩充"这四个字其实精准概括了C++的起源——它是带着对象导向特性的C超集，后来不断追加模板、lambda表达式、智能指针、右值引用、并发库等特性。这也意味着C++同时背负了三十多年的历史包袱，新老特性并存，同一个问题可能有好几种不同年代的解法。
Rust则是2015年才稳定发布1.0的新语言，设计上没有向后兼容几十年前代码的顾虑。它的语言特性相对一致，宏、泛型、模式匹配、切片这些能力彼此联动紧密。Rust里没有继承，而是用trait（特征）做抽象，用组合替代继承。写Rust时你会觉得语言本身提供的工具是自洽的，而非C++那种"为每个历史问题打补丁"的感觉。
3. 并发与异步模型实战
3.1 线程与共享内存的竞争条件
C/C++项目用pthread或std::thread开线程，用mutex、condition_variable同步数据，这是大多数服务端的标配。由于编译器对内存序的放宽和CPU乱序执行，还会引入atomic和内存序（memory order）概念。
这些规则非常细碎，而且出问题时很难复现。比如我遇到过的一个线上问题：某个C++服务偶发崩溃，花了整整三天排查，最后发现是多个线程并发写同一个unordered_map导致的内部指针被破坏。这种bug在编译期毫无提示，运行时才偶然暴露。
Rust的Send/Sync trait从类型层面约束了"什么数据能跨线程传递"，"什么数据能共享访问"。如果你的类型里包含Rc（引用计数但非线程安全），那么它默认不能跨线程传递，编译器会因为Send约束不满足直接报错。这种约束有效厘清了并发安全边界，很多并发问题在写代码阶段就被拦截了。
再比如数据竞争，借用检查器对多线程同样生效。两个线程共享同一个可变引用？编译失败。必须通过Arc<Mutex >或者Arc<RwLock >包装，让"锁"成为数据访问的唯一通道。虽然要写更多样板代码，但比运行时崩溃好排查得多。
3.2 异步编程：C++20 coroutine与Rust async
服务端开发避不开高并发场景，异步编程也就成了两个生态共同的重点。
C++20引入了协程co_await/co_yield，但标准库层面的配套还比较有限，需要依赖各种第三方库搭建事件循环。Rust这边async/await语法和标准库配套相对成熟，生态中tokio、async-std这些运行时已经构建得很完整。用tokio写一个TCP echo server，十几行代码就能跑起来。
use tokio::net::TcpListener; use tokio::io::{AsyncReadExt, AsyncWriteExt}; #[tokio::main] async fn main() -> Result<(), Box<dyn std::error::Error>> { let listener = TcpListener::bind("127.0.0.1:8080").await?; loop { let (mut socket, _) = listener.accept().await?; tokio::spawn(async move { let mut buf = [0u8; 1024]; loop { let n = match socket.read(&mut buf).await { Ok(n) if n == 0 => return, Ok(n) => n, Err(_) => return, }; if socket.write_all(&buf[..n]).await.is_err() { return; } } }); } }这段代码直观展示了Rust异步的两个要点：async块默认是惰性的，不执行到.await不会真正驱动Future；而tokio::spawn会把Future丢到当前运行时的任务队列里并行执行。整体并发模型比C++里手动管理epoll事件循环要清晰很多。
4. 互操作：让C/C++和Rust项目并肩作战
4.1 FFI：C ABI作为共同语言
现实中我们经常需要让C/C++项目与Rust项目互通。做法是利用C ABI（应用二进制接口）作为中间层，Rust里用#[no_mangle]导出函数，然后通过extern "C"声明C函数，让两边互相调用。
从Rust调用C库的写法：
use std::os::raw::c_int; extern "C" { fn abs(input: c_int) -> c_int; } fn main() { unsafe { println!("C abs(-5) = {}", abs(-5)); } }从C++调用Rust库的写法，在Rust侧用#[unsafe(no_mangle)] pub extern "C"导出符号，编译成静态库或动态库，C++头文件里声明对应的extern函数签名即可。
整个过程有几个关键点需要注意：
- 类型映射：Rust的i32对应C的int32_t，Rust的u64对应C的uint64_t，不要用C的int到Rust的i32想当然，需要按平台位数逐一确认。
- 字符串转换：Rust的String并不以\0结尾，直接传给C会出大问题，必须通过CString转换。
- 结构体对齐：默认不对接，需要用
#[repr(C)]标注结构体内存布局，否则C侧读取的字段偏移会错乱。 - 错误处理：Rust的Panic不允许跨越FFI边界，必须捕获并转换成错误码返回。
网上报错"c# dll调用c\c++ dll，报错:system.accessviolationexception: attempted to read or write protected memory"就是典型的FFI越界问题。原因通常是C++ DLL导出的指针或缓冲区管理不当，或是C#传入了错误类型的委托/结构体。如果换成Rust做的DLL，内存安全边界更清晰，反过来出这类问题的概率会低很多，但FFI边界上的类型匹配依然需要谨慎。
4.2 ABI兼容问题
C/C++的ABI没有标准化，同一个编译器不同版本可能产生不同符号修饰规则（name mangling），不同编译器更不用说。这就是为什么C++库要区分MSVC、GCC、Clang不同的构建版本。Rust的ABI兼容策略则更加克制，标准库对外部ABI的依赖很有限，跨编译器发布Rust静态库更容易保持一致。
如果你只是在Rust里调用一个C++类库，由于C++的类方法和虚表布局跨编译器不稳定，更稳妥的路线是：先把C++类封装成一组extern "C"函数，再给Rust做FFI。Rust侧不要直接依赖C++的二进制ABI，这是我在混合语言项目里学到的最大教训。
4.3 真实场景：OPC UA客户端与嵌入式开发
热词里出现了"windows c/c++ opc ua客户端编程"和"freeopcua与opc62541哪个好用"，这正是C/C++和Rust互操作的一个典型工业场景。OPC UA是工业自动化里广泛使用的通信协议，C/C++生态有open62541（纯C实现）和freeopcua（C++封装）两套选择。open62541因为纯C编写，ABI稳定，更容易通过FFI接入Rust项目；freeopcua接口更面向对象，但跨FFI时需要的封装更复杂。
如果你正纠结这两个库，我的建议是：项目本身以C++为主，选freeopcua，写起来更顺手；如果后期有引入Rust模块的规划，选open62541更稳妥，因为纯C接口做Rust绑定最简单。
热词里还有"esp32 rust开发"和"rust嵌入式开发"。嵌入式场景下C/C++长期是主角，但Rust的embedded-hal、esp-rs这些项目已经在快速成熟。ESP32上做Rust开发，espup工具链装好后，cargo build直接生成固件，和C/C++的idf.py sdkconfig折腾流程比，上手成本差异挺大。
Rust嵌入式的核心优势还在于"不安全的边界最小化"，尤其涉及寄存器操作、中断服务程序这类容易出错的部分，Rust的类型系统能限制很多危险操作。不过硬件厂商的SDK目前还是C/C++为主，Rust绑定的完善度要看具体芯片平台。
4.4 在线进程打补丁与系统级工具
热词里面还有"rust在线进程打补丁"和"rust程序抓包教程"。这两个场景正好体现了Rust在系统编程里的生态想象力。
在线进程打补丁本质是运行时修改内存或热更新代码路径，这属于高难度操作。C/C++世界常见做法是ptrace附加到目标进程、注入so，或者修改机器码。Rust里做这件事的难度并不比C/C++低多少，因为最终还是要面对操作系统的进程模型。但Rust的强类型和内存安全特性，可以帮你把"补丁脚本本身"写得可靠一点，避免打补丁过程中把自己搞崩溃。
抓包工具方面，Rust有pcap、etherparse这些库，可以比较方便地处理链路层和IP层数据包。和C/C++的libpcap方案比，Rust的rspcap封装更友好，不用自己管理指针生命周期。想写一个命令行抓包分析小工具，Rust的体验明显比C++写filter表达式舒服。
5. 调试与工具链对比
5.1 C/C++的调试习惯
C/C++调试主要靠GDB或LLDB，配合IDE如VS Code的调试前端。遇到崩溃先开core dump，用gdb bt看堆栈。内存相关的问题还得上valgrind或AddressSanitizer。我早期排查内存泄漏，编译时得特意加上-fsanitize=address，跑一遍测试流程，再看report。这一套流程信息量很大，但是笨重，而且有时候问题只在release模式下复现，debug模式下反而不出现。
5.2 Rust的调试体验
Rust调试同样用gdb/lldb，或者VS Code的rust-analyzer配合调试插件。但由于编译器在编译期帮你解决了大量内存安全问题，运行时的崩溃场景比C/C++少得多。更多时候的调试压力集中在逻辑错误或并发时序这类问题上。
rust-analyzer这个语言服务器给IDE体验带来的提升很直观。C++的IntelliSense经常因为include路径配置不对而飘红，Rust侧则直接从Cargo.toml解析依赖，跳到第三方库源码查看定义基本秒开。
有网友在搜"rust vscode如何调试"，其实和C/C++的流程相似：安装rust-analyzer扩展，配置launch.json指向cargo build生成的二进制文件即可。Rust的调试信息比C/C++默认模式下更丰富，特别是枚举和Option 这类类型的可视化表现更好。
5.3 交叉编译与定制安装
热词里还有"rust安装"和"rust安装教程自定义路径"，这属于入门端的常见痛点。Rust官方推荐的rustup安装方式可以指定安装目录，环境变量RUSTUP_HOME和CARGO_HOME可以控制具体位置，方便不想把工具链装到系统目录的用户。离线安装Rust则可以用rustup-init配合已下载的组件包完成，还支持带标准库源码。
C++工具链的安装则是另一番景象，Linux下apt装gcc、g++、make、cmake，Mac下用xcode-select或者brew，Windows下得装Visual Studio或者MinGW-w64。发行版不同、编译器版本不同，行为也有差异。Rust工具链的跨平台一致性明显更好。
6. 选型建议与迁移避坑指南
6.1 什么项目适合继续用C/C++
C/C++依然是很多领域的事实标准，尤其在以下几个方向：
- 既有大型遗留系统：代码量巨大，重写成本远大于收益，更合理的做法是用Rust逐渐替换高风险的模块。
- 硬件厂商SDK依赖：很多嵌入式芯片和工业控制器的官方SDK只有C/C++版本，Rust绑定不一定完善。
- 极致性能调优场景：C/C++可以直接控制所有的汇编级微优化，Rust虽然也能做但受限于安全抽象，某些极边缘场景的优化自由度稍低。
6.2 什么项目适合迁移到Rust
如果你的项目符合以下特征，Rust单项优势非常明显：
- 网络服务端：大量并发连接，异步编程模型成熟，带类型系统的工具链能有效减少线上崩溃，tokio生态足够大。
- CLI工具和开发者工具：Rust编译成单一静态二进制，部署简单，用户体验好。ripgrep、fd、bat这些工具都是活证据。
- 安全敏感模块：需要解析不可信输入、处理加密、鉴权，内存安全可以杜绝一整类高危漏洞。
- 嵌入式固件中的非硬件紧耦合部分：官方SDK负责最底层，业务逻辑用Rust写能减少不稳定因素。
C/C++开发者在评估迁移时，最需要克服的不是语法差异，而是"内存管理不再靠自觉"这一关。第一次被编译器拒绝你的self.ptr = other.ptr赋值，第一反应往往是"这编译器是不是傻了"，但其实仔细想，这个裸指针赋值确实制造了两个拥有者。
6.3 C/C++转Rust的避坑清单
结合我自己从C++转Rust的经历，整理几条实操避坑经验：
- 不要试图一次性把一个大型C++类库重写成Rust，先挑一个基础设施模块动手，比如日志、配置解析、协议编解码这类边界清晰的模块。
- 先掌握所有权和借用再写业务代码。跳过这个直接写，你会陷入"编译器教我写代码"的沮丧感，而不是真正理解它为什么这样设计。
- 多用
cargo clippy，它会指出很多初学者容易犯的反模式。 - 异步编程不要一开始就上tokio精讲，先用标准库线程模拟并发场景，理解Send/Sync约束之后再切到async模型。
- Rust的trait对象和泛型与C++模板的关系不是一一对应，有些C++通过模板元编程优雅解出来的问题，在Rust里可能需要换一种方式思考。
7. 两个生态的技术债与长期维护
7.1 依赖管理的长期收益
C/C++项目长期维护的痛点之一是依赖关系模糊。很多老项目的third_party目录里直接躺着改过源码的第三方库，升级版本时根本不敢动，因为不知道之前改了什么。Rust的crates.io生态和Cargo.lock机制，至少让"当前项目依赖了什么版本、为什么依赖它"变得透明。
这个差别在大型团队协作中尤其致命。C++团队经常花大量时间处理"在我机器上编译不过"的问题，Rust项目里这种反馈明显更少。你要说Rust完全没有环境问题，也不是，但Cargo对依赖的确定性确实让跨平台、跨人的复现简单了很多。
7.2 社区生态的互补
两个社区并非零和博弈。C/C++的FFI生态依然重要，因为大量底层库都是C写的，Rust可以通过ffi用它们而不必全部重写。反过来，Rust写的静态库也可以嵌入到大型C++工程中，给新模块提供安全的基础。我现在的一个策略就是：老系统继续用C++维持稳定，新模块和涉及并发的高风险模块用Rust实现，通过FFI衔接。刚开始团队有些排斥，后来看到Rust模块带来的线上稳定性提升，大家也就接受了。
C/C++往Rust迁移不是一场革命，而是一种渐进式改良。你不必二选一，而是可以让它们在同一个系统里各施所长，用C ABI作为桥梁。
7.3 学习路径建议
如果你是从C/C++转到Rust的开发者，建议按这个顺序学：
- 先理解所有权、借用、生命周期，并多做小练习（比如自己实现一个链表），感受编译器的约束逻辑。
- 再学习常用的集合类型和迭代器链式调用，这些比手写循环更符合Rust的惯用法。
- 然后接触std::thread和多线程同步API，配合Mutex、Arc练习并发安全。
- 最后进入异步编程，选择tokio并模仿官方示例写一个TCP服务或HTTP客户端。
- 试着用Rust重新实现一个你以前用C++做过的小工具，对比两次开发的体会。
网上的"rust权威指南第二版"PDF流传很广，中文社区也翻译得不错。我建议手头备一本电子版方便查阅，但真正理解还是靠自己动手写出来的代码。语言特性从"知道"到"会用"，中间永远是隔着几千行练习的距离。
热词里还有人搜"c语言和java和python和c++"怎么选，这类问题不必想得太复杂。如果你在意高性能系统编程和嵌入式，C++和Rust都是正路；Rust在安全性上有先天优势，C++在历史积累和生态广度上更厚实。两者互相补充，而不是你死我活的关系。
8. 实际项目中的经验心得
8.1 一次C++模块迁移到Rust的复盘
去年年初，我负责的一个工业网关项目里有一个负责协议解析和设备管理的C++模块，代码约两万行。它的问题是：涉及多线程共享设备状态，还引入了不少第三方库，线上偶发崩溃。崩溃后日志看不出什么，core文件分析出来的堆栈也经常指向库内部。
后来我下决心用Rust重写这个模块。过程没有想象的激进——先画清楚模块的边界和原有接口，用FFI封装成动态库给C++主程序调用，然后逐个子模块迁移。真正写Rust只花了两周，但设计接口和跑兼容性测试花了一个多月。这里最大的成本其实不是写代码，而是理解原来模块里所有隐藏的状态机和边界行为。
重写完成后是个双层的体验：线上崩溃清零，内存占用还降了不少；但构建过程比原来C++模块简单太多，部署时直接把.so丢过去就行。团队里原本持怀疑态度的老C++同事，看到编译期安全检查拦住的问题以后，也开始认可这个方向。
8.2 踩过的一些坑
Rust的编译期保证并不是万能的。它不是不会崩溃，只是把崩溃概率压低到一个很低的水平。我遇到过的几个实际坑包括：
- 在异步任务里持有MutexGuard跨.await触发"Future is not Send"错误，这个问题在写TCP长连接处理时很常见。解决办法是把锁的持有范围尽量缩小，或者在锁外准备好数据再做异步操作。
- 用Rc在单线程里写业务状态，后来模块逐步扩展被挪到一个多线程上下文时，编译器直接拒绝编译，只能把Rc改成Arc。
- FFI边界上忘了处理panic，Rust侧的一次panic把整个宿主C++进程都崩了。后来我养成了每个FFI入口函数都包一层catch_unwind的习惯。
- 误用transmute或者裸指针操作，绕过安全检查。排查起来比直接在C++里裸指针还麻烦，因为它骗过了编译器，却依然产生未定义行为。这种代码后来全被code review禁止了。
我想说的是，Rust虽然安全性高，但写不安全代码的能力依然保留，这既是一个逃生舱，也是一道锁。你必须清楚什么时候用、怎么用、以及承担什么责任。
8.3 最后补充一个实用小技巧
如果你在C/C++项目里逐步引入Rust，给别人交付动态库时，建议用cargo build --release生成release版本，并且用strip减小体积。还要注意Rust的动态库对glibc版本有依赖，在比较老的Linux服务器上可能报加载失败，这时候编译时加上-C target-feature=+crt-static静态链接C运行时可以解决一部分问题。
另外一个从C++生态带过来的习惯——写基准测试——在Rust里也很容易做。标准库自带#[bench]，或者用criterion库做更专业的统计测试。性能优化时不要凭感觉，测出来看数据，哪里是瓶颈就优化哪里，这和C++的优化思路完全一致。
