Cloudflare近期的一次服务崩溃事件引发了广泛讨论，据分析可能与代码中未妥善处理的unwrap()有关。这给我们提了个醒：即便在Rust这样以安全著称的语言中，也存在不少“危险操作”，若使用不当，同样可能导致服务不稳定甚至崩溃。本文将系统性地梳理Rust代码中那些需要警惕的操作，分析catch_unwind为何有时会失效，并介绍一些实用的第三方捕获工具。
一、危险操作一览
我们按照行为对程序可控性的影响程度，将危险操作分为三个等级。这里先排除明确使用unsafe关键字的情况，因为其危险性已由关键字明示。从低到高，大体可分为以下三类。
1、低危险
这类操作通常不会直接导致程序崩溃或内存错误，但可能埋下性能隐患或逻辑缺陷。
1.1、 乱用clone
clone本身不会产生未定义行为(UB)，也不会panic。但滥用它可能埋下性能炸弹，且问题非常隐蔽。
- 原因
- 大对象深拷贝：某些类型的
clone是深拷贝，例如let b = a.clone();。如果a是Vec<T>（内含大量数据）、Arc<Mutex<T>>（内部包裹了大结构体）或自定义struct包含大对象，那么clone()会重新分配内存并复制一整份数据。这可能导致内存使用激增、程序延迟飙升、吞吐量下降。这类问题在常规的代码审查(CR)中很难一眼识别。
- 高并发下频繁克隆Arc：在多线程场景下，每次克隆
Arc都需要原子性地更新同一个内存地址上的引用计数器。这会导致线程间争用，部分线程不得不等待原子操作完成和缓存同步，从而挤占本该处理业务逻辑的时间。
- 多线程复制锁：原子操作本身开销不小，如果频繁克隆包含锁的结构，会增加更多的内存共享冲突。
- 乱用的例子
fn foo(s: &String) {
let x = s.clone(); // 逃避生命周期检查
}
说明：这段代码通常能运行，但属于通过克隆来回避Rust的生命周期检查，并非最佳实践。
- 循环内clone，造成性能灾难
for _ in 0..10000 {
let v2 = v.clone(); // 大向量被复制一万次
}
1.2、整数溢出（wrapping）
整数溢出在 Debug 模式下会触发panic，但在 Release 模式下，默认的算术运算会进行环绕 (wrapping)，而不报错，这可能导致逻辑错误。例如：
let size = a * b; // 可能溢出
let ptr = alloc(size); // size可能是负数、0等，导致分配了错误大小的内存，进而破坏内存
可以使用以下方法替代（类似的还有checked_mul、saturating_mul等）：
checked_add：溢出时返回None，安全地处理失败。overflowing_add：返回结果和一个布尔值，指示是否发生溢出。saturating_add：溢出时会将结果限制在该类型的最大值或最小值，既不panic也不环绕。
fn safe_overflow_demo() {
let max = i32::MAX;
match max.checked_add(1) {
Some(v) => println!("v={}", v),
None => println!("overflow detected"), // 输出: overflow detected
}
}
2、中危险
这类操作会在运行时导致程序崩溃（panic），但这是可预期的行为，不会破坏内存安全或编译器的基本假设。
2.1、expect()
它与unwrap()一样会触发panic，只是允许自定义错误信息。适用于快速原型开发和Demo，但不应在生产代码中使用。应改用?操作符或显式的错误处理（match、map_err）。
2.2、 panic!()
调用此宏会立即使程序崩溃，并触发栈展开(unwinding)（除非配置为panic=abort）。通常仅在调试时使用，不适合用于生产系统的流程控制。应使用Result<T, E>返回错误，或借助thiserror、anyhow等错误处理库。
- Demo
fn safe_panic_demo(input: Option<i32>) -> Result<i32, String> {
match input {
Some(v) => Ok(v),
None => Err("input is None".to_string()),
}
}
2.3、数组越界
这有两种情况：使用[]索引访问越界会触发Panic（安全的行为）；使用get_unchecked()或*v.as_ptr().add(i)等unsafe操作越界则可能导致未定义行为(UB)。据说越界访问是Rust中最常见的UB来源之一。
-
Demo
fn main() {
let v: Vec<i32> = vec![10, 20, 30];
let index_safe: usize = 1;
let index_oob: usize = 5; // 越界索引，有效范围是 0..3
println!("--- 1. 安全访问方法 (Safe Access) ---");
// 1.1. `v.get(x)` -> 返回 `Option<T>`，安全地处理越界
match v.get(index_safe) {
Some(val) => println!("v.get({}) (安全, 有效): {}", index_safe, val),
None => println!("v.get({}) (安全, 越界): 返回 None", index_safe),
}
match v.get(index_oob) {
Some(val) => println!("v.get({}) (安全, 有效): {}", index_oob, val),
None => println!("v.get({}) (安全, 越界): 返回 None, 程序继续", index_oob),
}
println!("\n--- 2. 运行时检查访问方法 (Runtime Panic) ---");
// 2.1. `v[x]` -> 越界时触发 `panic!`，中止程序
println!("v[{}] (安全, 有效): {}", index_safe, v[index_safe]);
// 取消注释下方代码块以观察 panic! 行为
// println!("尝试 v[{}] (越界, panic)...", index_oob);
// let _val_panic = v[index_oob]; //index out of bounds: the len is 3 but the index is 5
// println!("此行不会被执行");
}
3、极度危险
这类操作可能跳过编译器和运行时的安全检查，直接导致未定义行为(UB)，破坏程序状态。
3.1、unwrap_unchecked()
此操作跳过所有检查，直接取值。如果Option是None，会导致UB（未定义行为），而不仅仅是普通panic。仅适用于极少数被严格证明安全的、对性能有极致要求的场景，如编译器内部或手工优化的代码。
3.2、 mem::transmute
mem::transmute被认为是极度危险的操作（Rust unsafe中最危险的之一）。它会完全跳过Rust的类型系统，将一段内存的比特位强行解释为另一种类型，而编译器不做任何合理性检查。仅适用于底层优化或与外部ABI对接。通常可以用枚举/结构体、From/TryFrom trait来替代。
| 想做的事 |
不要用 |
应该用 |
| 数字 → 字节数组 |
transmute |
.to_ne_bytes() |
&T → &U |
transmute |
reinterpret_cast 方案：ptr.cast() |
| 类型安全转换 |
transmute |
From / Into / TryFrom |
| C ABI struct 转换 |
transmute |
#[repr(C)] + 指针转换 |
Option<Box<T>> 优化大小 |
transmute |
Option::take 或 ManuallyDrop |
| 枚举判别值操作 |
transmute |
std::mem::discriminant |
二、catch_unwind为什么有时候捕获不到崩溃
通常，我们会使用panic::catch_unwind来捕获panic，用std::panic::set_hook记录日志和堆栈，或用GDB/LLDB等调试器记录系统级崩溃。其中只有catch_unwind能实现优雅的错误处理，保持服务继续运行。这里主要探讨它。
1、panic::catch_unwind 是如何工作的？
- panic可以理解为“强制异常 + 栈回退”。它会执行栈展开 (stack unwinding)，逐层释放（drop）栈帧上的变量。如果无法继续展开，进程将直接终止(abort)。
-
Rust是如何“展开”栈的？什么是unwind?
fn a() { b(); }
fn b() { c(); }
fn c() { panic!("boom"); }
a();
┌──────────┐
│ a() │
└───▲──────┘
│ calls
┌───┴──────┐
│ b() │
└───▲──────┘
│ calls
┌───┴──────┐
│ c() │ ← panic 发生
└──────────┘
unwind的过程如下：
c() 退出，drop c 中的变量。- 回到
b()，drop b 中的变量。
- 回到
a()，drop a 中的变量。
- 如果在某处设置了
catch_unwind，则停止回退。
- 否则，一直退到线程根部并结束该线程。
每一步都是栈帧被弹出（pop stack frame）并执行资源释放，这就是“展开(unwind)”。
-
增加catch_unwind后：它能捕获当前线程中由panic触发的正常栈展开，并返回 Result<(), Box<dyn Any + Send>>。
use std::panic;
let result = panic::catch_unwind(|| {
panic!("boom");
});
assert!(result.is_err());
2、捕获不到的场景
2.1、panic 被设置为 abort
在 Cargo.toml 中配置：
[profile.release]
panic = "abort"
此时，发生panic时进程会直接终止，既不进行栈展开，也不执行drop清理。catch_unwind根本没有机会执行。
2.2、跨语言边界
panic发生在跨FFI/外部库边界时，尤其是与非Rust语言（如C或C++）交互，栈展开(abort)行为是不确定的，catch_unwind未必能捕获到。参考 Rust官方文档。
2.3、unsafe 导致的 UB 可能不被 catch_unwind 捕获
当在unsafe代码中触发未定义行为(UB)时——例如通过裸指针非法读写、使用悬垂引用、违反借用/别名规则、数据竞争、对齐错误等——这在语言层面没有明确定义。它可能产生任意结果：程序崩溃、数据损坏、继续运行但状态错乱、内存泄漏……这类错误不走 panic/unwind 机制。UB本身意味着结果是未定义的，因此代码流程也不确定，catch_unwind大概率无法捕获。
三、第三方抓取工具
1、FutureExt
来自 futures 库，它允许直接在 async Future 上捕获 panic，支持链式调用等便捷操作。
地址：https://github.com/rust-lang/futures-rs
use futures::FutureExt; // 0.3.5
#[tokio::test]
async fn test_async() -> Result<(), Box<dyn std::error::Error>> {
println!("before catch_unwind");
let may_panic = async {
println!("inside async catch_unwind");
panic!("this is error")
};
let async_result = may_panic.catch_unwind().await;
println!("after catch_unwind");
assert!(async_result.is_ok());
Ok(())
}
Future内部的panic被catch_unwind捕获并转换为Result::Err。
2、tower-http的catch-panic
这是一个中间件，用于捕获HTTP handler中的panic，并将其转换为合适的HTTP错误响应（例如500），防止服务进程退出。
https://docs.rs/tower-http/latest/tower_http/catch_panic/index.html
use http::{Request, Response, header::HeaderName};
use std::convert::Infallible;
use tower::{Service, ServiceExt, ServiceBuilder, service_fn};
use tower_http::catch_panic::CatchPanicLayer;
use http_body_util::Full;
use bytes::Bytes;
async fn handle(req: Request<Full<Bytes>>) -> Result<Response<Full<Bytes>>, Infallible> {
panic!("something went wrong...")
}
let mut svc = ServiceBuilder::new()
// Catch panics and convert them into responses.
.layer(CatchPanicLayer::new())
.service_fn(handle);
// Call the service.
let request = Request::new(Full::default());
let response = svc.ready().await?.call(request).await?;
assert_eq!(response.status(), 500);
在axum中也可使用：https://github.com/tokio-rs/axum/discussions/1865
tower-http = { version = "0.5", features = ["catch-panic"] }
代码：
use tower_http::catch_panic::CatchPanicLayer;
...
let app = Router::new()
.route("/", get(ok_handler))
.route("/panic", get(panic_handler))
// 加上 CatchPanicLayer
.layer(CatchPanicLayer::new());
...
发生panic时将返回HTTP 500 Internal Server Error，服务进程不会退出。
3、tokio::spawn自带的工具
let handle = tokio::spawn(async {
panic!("boom!");
});
let result = handle.await;
if let Err(join_err) = result {
if join_err.is_panic() {
println!("panic caught!");
}
}
在Tokio运行时中，每个任务都是独立执行的。如果任务内部panic，spawn返回的JoinHandle在await时会得到一个JoinError，通过其is_panic()方法可以判断是否因panic而失败。这是一种有效的异常捕获与隔离机制。
四、总结
本文系统梳理了Rust代码中从低到高的三类危险操作，并解释了panic::catch_unwind的捕获原理及其失效场景。在实践中，我们可以在代码提交阶段引入lint工具，阻止含有unwrap等危险模式的代码入库；在服务运行时，如果性能允许，应积极使用兜底机制来捕获崩溃，这能处理绝大部分panic情况。
对于后端服务，从工程经验看，通常还需要结合灰度发布、自动回滚、熔断限流等更多保护性措施。Cloudflare此次服务崩溃，很可能是多种因素叠加的结果，单个unwrap的威力或许没这么大。当然，Rust中可能还存在其他危险操作，欢迎大家在云栈社区的Rust板块深入讨论。
发表于 2 小时前
|
查看: 4|
回复: 0
