老周经营一家修车铺二十年。他常跟徒弟说：“车在路上跑，靠的是安全带、气囊、ABS 这些主动安全系统；可到了车间里，要调发动机、查油路，就必须掀开引擎盖，把手伸进高温零件之间。”Rust 之于程序员，就像一台装满安全系统的车。平时写代码，编译器每时每刻帮你检查内存、类型、并发；但当你需要直接操作内存地址、调用 C 库或做底层系统对接时，就得像老周那样掀开引擎盖。这块“掀开引擎盖”的区域，就是 Unsafe Rust。本篇文章将带你看清引擎盖下的零件：五种 unsafe 操作、裸指针、可变静态变量、联合体、安全抽象封装、FFI 以及最后的审计清单，让你既能放心修车，又不把道路安全丢在脑后。

岗位关联

掌握 Unsafe Rust 的边界意识，是 Rust 工程师进阶底层系统、性能优化与 FFI 开发的硬门槛，也是大厂面试的高频考点。

目录
  1. 可视化演示
  2. unsafe块与函数：掀开引擎盖的一小块区域
  3. 五种unsafe操作：挂在红钩上的五把钥匙
  4. 裸指针详解：直接用手摸发动机零件
  5. 可变静态变量：全店共用的那张维修台
  6. 联合体与unsafe trait：多用途工具箱与技师资格证
  7. 安全抽象封装：给危险零件加上防护罩
  8. FFI与C互操作：隔壁修车铺的专用工具
  9. 原则与审计：维修手册与收工检查单
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示Unsafe Rust五种操作、安全抽象封装三层架构，以及FFI外部函数接口调用C库的双向数据流。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Unsafe五种操作 解引用裸指针(Ptr)、调用unsafe函数(Fn)、访问可变静态变量(Sta) 访问联合体(Uni)、实现unsafe trait(Trt) unsafe { *ptr; unsafe_fn(); &mut STATIC; } 五种操作必须包裹在unsafe块中，编译器不做安全检查

unsafe块与函数：掀开引擎盖的一小块区域

老周平时开车，安全带、气囊、ABS 全都在位，这是 Rust 给你的“默认安全模式”。但当他需要检查机油、拧紧火花塞时，他不会把整辆车拆散，只打开引擎盖那一小块。unsafe 块就是引擎盖：只在被指定的几行代码里，允许你做“危险动作”，其他代码照常受保护。

unsafe 有两种常见形态。unsafe { ... } 是“维修区”，只对花括号内的语句开放权限；unsafe fn 则是“危险设备”，任何调用者都必须主动踏入维修区才能使用它。两者的共同点是：编译器不再替你把关某些操作，责任转移到你手上。注意，unsafe 并不会关闭借用检查器，类型检查也依然生效，它只是额外放开了五类操作的门禁。

用集合把五类操作记录下来，帮助记忆：

老周修完车总会把引擎盖盖好，回到驾驶座上继续享受安全系统。你也应该在 unsafe 块结束后“盖好盖子”，让普通的借用检查和类型检查重新接管一切。

Sunsafe={∗p, funsafe(), Gmut, u.field, implunsafe trait}\displaystyle S_{\text{unsafe}} = \{ \ast p,\ f_{\text{unsafe}}(),\ G_{\text{mut}},\ u.\text{field},\ \text{impl}_{\text{unsafe trait}} \}
这个公式把需要“人工保证安全”的五种操作集中展示，核心思想是：只有这五件事需要你额外负责，其他一切安全检查照常。
  1. 裸指针解引用 $\ast p$对裸指针取值时，编译器无法验证指针是否有效，必须由你保证指向合法内存。
    ∗p:T\displaystyle \ast p: T
  2. 调用 unsafe 函数 $f_{\text{unsafe}}()$函数内部可能访问了不安全状态，调用者需要阅读其文档并承诺满足前置条件。
    funsafe():T\displaystyle f_{\text{unsafe}}(): T
  3. 读写可变静态变量 $G_{\text{mut}}$全局共享数据可能被多个线程同时访问，读写操作必须人工保证同步。
    Gmut:read/write\displaystyle G_{\text{mut}}: \text{read/write}
  4. 访问联合体字段 $u.\text{field}$联合体同一块内存有多种解释方式，读取时需确认当前存的是哪种类型。
    u.field:T\displaystyle u.\text{field}: T
  5. 实现 unsafe trait $\text{impl}_{\text{unsafe trait}}$实现者需自己验证 trait 的契约，编译器无法自动推导。
    impl UnsafeTrait for T\displaystyle \text{impl}\ \text{UnsafeTrait}\ \text{for}\ T

五种unsafe操作：挂在红钩上的五把钥匙

老周的维修间墙上挂着一个红色钩子，上面只有五把钥匙。徒弟问为什么单独挂开，他说：“这五把钥匙一旦用了，责任就是你的，不是车的。”在 Rust 里，unsafe 能做的事也只有五件，全部是编译器无法替你验证的底层操作。

第一是把钥匙是解引用裸指针，直接透过地址取值；第二是调用 unsafe fn，进入一个声明了“本函数不可自证安全”的代码；第三是读写 static mut，访问全局可变状态；第四是读取联合体字段，把同一块内存按另一种类型解释；第五是实现 unsafe trait，承诺为某个 trait 的安全契约背书。除此之外，unsafe 并不赋予你“为所欲为”的权限——你依然不能绕过借用规则去制造悬垂引用，该受检查的照样受检查。

五把钥匙让老周的维修工作高效，但每次用完都要放回红钩子。对程序员来说，这五类操作就是你的危险清单，知道它们、敬畏它们，才能安全地使用真正的底层能力。

∀ op∈Sunsafe: 需要 unsafe 上下文\displaystyle \forall \ \text{op} \in S_{\text{unsafe}}:\ \text{需要}\ \text{unsafe}\ \text{上下文}
该公式强调：五个操作是“强制的 unsafe 清单”，只要你在普通安全代码里触碰它们，编译器就会拒绝编译。
  1. 全称量词 $\forall$对于集合中的所有操作，规则都成立，没有任何例外。
    ∀\displaystyle \forall
  2. 属于符号 $\in$操作 op 属于五元素集合，代表它是被点名的危险操作之一。
    op∈Sunsafe\displaystyle \text{op} \in S_{\text{unsafe}}
  3. 需要 unsafe 上下文每个操作在执行前，必须包裹在 unsafe {} 或 unsafe fn 中，否则无法通过编译。
    需要 unsafe 上下文\displaystyle \text{需要}\ \text{unsafe}\ \text{上下文}

裸指针详解：直接用手摸发动机零件

戴手套修车是标准流程，但有些精密零件必须摘掉手套才能感知磨损。Rust 的裸指针就是“摘掉手套”的手指：*const T 和 *mut T 不会自动管理内存，不保证指向有效数据，也没有生命周期约束。它像一把没有保护套的螺丝刀，能精确够到零件，但容易戳伤自己。

裸指针可以通过 as 从普通引用转换而来，也可以从 Box::into_raw 或外部地址获得。解引用裸指针必须在 unsafe 块中完成，因为编译器无法确认指针是否悬空、对齐是否正确。与引用不同，裸指针不参与借用检查，也没有“别名规则”保护，多个裸指针可以同时指向同一块内存，后果要自己负责。

老周摘掉手套摸完零件，马上会把手套戴回去。裸指针用完后也应该尽快转回引用或装箱，让 Rust 的安全机制重新接管内存，避免“光手”在引擎室里待太久。

p:∗constT,∗p:T\displaystyle p: \ast_{\text{const}} T, \quad \ast p: T
这个式子表达了裸指针的本质：p 只是一个地址，解引用之后才能得到 T 类型的值；这一步是危险的，必须人工保证 p 有效。
  1. 指针类型 $p\ast_{\text{const}} T$：声明 p 是一个指向 T 的不可变裸指针，它只是一个地址值。
    p:∗constT\displaystyle p: \ast_{\text{const}} T
  2. 解引用得到值 $\ast pT$：使用星号操作符访问指针指向的内存，产出 T 类型的值。
    ∗p:T\displaystyle \ast p: T
  3. 安全性条件解引用前，p 必须指向已分配且对齐正确的内存，且不能同时存在可变别名写入。
    valid(p)⇒∗p safe\displaystyle \text{valid}(p) \Rightarrow \ast p\ \text{safe}

可变静态变量：全店共用的那张维修台

维修车间正中央放着一张铁制工作台，所有技师都可以把零件摆上去。一旦两个技师同时抢用，零件就会撞在一起。Rust 的可变静态变量 static mut 就是这张公共维修台：全局只有一份，任何代码都能读写，编译器无法保证线程之间没有冲突。

读取和写入 static mut 都需要 unsafe 块。最基本的原因很简单：多个线程同时读写同一块全局内存，会产生数据竞争，而数据竞争在 Rust 的内存模型里属于未定义行为。这不是“编译不通过”这么温柔，而是程序可能以任何人无法预料的方式崩溃。实际工程中，我们很少直接用 static mut，而是用 Mutex、RwLock 或原子类型把数据包起来，再对外提供安全 API。

老周后来给公共工作台装上了“预约锁”，谁用谁取钥匙，其他人只能等。Rust 里用 Mutex 或原子类型就是这把锁。让公共资源有序访问，整间修车铺才能安全运转。

static mut G:T,race(G)⇒UB\displaystyle \text{static mut}\ G: T, \quad \text{race}(G) \Rightarrow \text{UB}
该式说明：可变静态变量一旦产生竞争（race），就会进入未定义行为（UB），程序可能产生任何结果。
  1. 声明全局变量 $\text{static mut}\ GT$：G 是全局唯一的可变变量，生命周期贯穿整个程序。
    static mut G:T\displaystyle \text{static mut}\ G: T
  2. 竞争条件 $\text{race}(G)$多个任务同时读写 G，且至少一方是写操作，就构成数据竞争。
    race(G)\displaystyle \text{race}(G)
  3. 未定义行为 UB竞争发生后，编译器不再保证任何行为，程序可能崩溃、卡死或输出错误结果。
    race(G)⇒UB\displaystyle \text{race}(G) \Rightarrow \text{UB}

联合体与unsafe trait：多用途工具箱与技师资格证

老周工具箱里有一个“多用途接头”，同一个接口既能接扳手，也能接套筒，装什么由现场决定。Rust 的联合体 union 正相反：同一块内存，可以按字段 A 解释，也可以按字段 B 解释，但同一时刻只会有一个“真实身份”。编译器无法知道当前该按哪种类型读取，所以访问联合体字段必须在 unsafe 块里。

另一个概念是 unsafe trait。如果把 trait 比作一种技师资格证，普通 trait 是“考试通过自动发证”，unsafe trait 则是“先发证后抽查”——实现者必须自己证明满足约定。最经典的例子是 Send 和 Sync 的某些手动实现：你告诉编译器“这个类型可以安全地跨线程传递”，但这个承诺一旦说错，后果不堪设想。

老周的多用途接头用之前，总要看看标签确认当前装的是哪种工具。联合体的字段访问也需要这种“看标签”的谨慎。至于技师资格证，拿到手越容易，出事故时责任越重——unsafe trait 正是这样一张需要持续背书的证书。

union U {a:i32, b:[u8;4]},u.a:i32\displaystyle \text{union}\ U\ \{ a: i32,\ b: [u8;4] \}, \quad u.a: i32
联合体强调内存复用：同一个位置，可以按 i32 读，也可以按字节数组读；读取前必须确认“现在存的是什么”。
  1. 定义联合体 $\text{union}\ U\ \{ ai32,\ b: [u8;4] \}$：U 占据一块大小为 max 的内存，a 和 b 是这块内存的两种视图。
    union U {a:i32, b:[u8;4]}\displaystyle \text{union}\ U\ \{ a: i32,\ b: [u8;4] \}
  2. 访问字段 $u.ai32$：按字段 a 读取内存，将位模式解释为 i32；如果实际存的是 b，结果就是无意义的乱码。
    u.a:i32\displaystyle u.a: i32
  3. 安全前提访问前，代码必须保证当前联合体实例中“活跃”的成员与读取字段一致，这只能靠人工维护。
    active(u)=a⇒u.a safe\displaystyle \text{active}(u) = a \Rightarrow u.a\ \text{safe}

安全抽象封装：给危险零件加上防护罩

老周发现，店里最熟练的技师也有失误的时候。于是他定下规矩：凡是涉及裸露零件的操作，必须先把零件装进一个带防护罩的专用工具里，再交给其他人使用。Rust 中的安全抽象封装，正是把 unsafe 的复杂细节藏在一个模块或类型内部，对外只暴露安全接口。

设计上，典型的模式是：内部使用裸指针或全局状态，外部提供安全方法。比如标准库的 Vec，其内部用裸指针管理堆内存，扩容、缩容都在 unsafe 中完成，但调用者只需使用 push、pop 等方法，完全不接触 unsafe。关键在于维护“不变量”：例如 Vec 保证 len <= capacity、指针指向有效分配区域。只要内部不变量成立，对外方法就是安全的。

老周给工具装防护罩后，新徒弟也能放心使用。设计安全抽象的关键就是：把危险限制在一个可控的小盒子里，让盒子外的人永远看不见尖角。这既提高了安全性，也极大降低了团队的认知负担。

∀x∈domain: inv(x)⇒safe(op(x))\displaystyle \forall x \in \text{domain}:\ \text{inv}(x) \Rightarrow \text{safe}(\text{op}(x))
该式表示：如果输入 x 满足不变量 inv，那么操作 op(x) 就是安全的，调用者无需了解内部 unsafe 细节。
  1. 任意输入 $\forall x$对类型定义域里的任何合法实例，结论都成立。
    ∀x∈domain\displaystyle \forall x \in \text{domain}
  2. 不变量 $\text{inv}(x)$x 满足类型维护的约束，比如指针非空、长度未越界、状态已初始化。
    inv(x)\displaystyle \text{inv}(x)
  3. 安全操作 $\text{safe}(\text{op}(x))$在不变量成立的前提下，执行操作 op 不会触发未定义行为，调用者无需进入 unsafe。
    inv(x)⇒safe(op(x))\displaystyle \text{inv}(x) \Rightarrow \text{safe}(\text{op}(x))

FFI与C互操作：隔壁修车铺的专用工具

有时老周自己的工具不够用，得去隔壁 C 师傅的修车铺借一把特殊扳手。跨店借工具不算难，但工具的大小、用法、归还方式都不一样。Rust 调用 C 库的能力叫 FFI（外部函数接口），核心机制是 extern "C" 块声明外部函数。

声明一个 C 函数需要给出参数和返回值的类型，例如 extern "C" { fn strlen(s: *const c_char) -> usize; }。因为 C 函数不经过 Rust 的内存检查，所以调用它必须在 unsafe 块中。更重要的是，跨 FFI 边界传递的指针所有权必须由程序员管理：谁负责释放内存？指针在哪个语言中分配？这些问题没有编译器帮忙，全靠约定。ABI 匹配也是一个关键点：调用约定、结构体布局必须与 C 侧一致，否则数据解读就会出现偏差。

老周从隔壁借来的工具，用完一定亲手还回去，绝不让人代还，因为只有他知道这把工具当初从哪个柜子里拿的。FFI 也一样：跨语言的内存所有权必须由同一套约定贯穿始终，才能在两个修车铺之间安全协作。

extern "C" { fn strlen(s:∗constc_char)→usize }\displaystyle \text{extern}\ "C"\ \{\ \text{fn}\ \text{strlen}(s: \ast_{\text{const}} \text{c\_char}) \to \text{usize}\ \}
FFI 声明本质上是告诉 Rust：外面有一个 C 函数，按 C 的 ABI 调用，参数是字符串指针，返回长度。
  1. extern "C" 块声明一段遵循 C 调用约定的外部函数列表，供 Rust 引用。
    extern "C" { … }\displaystyle \text{extern}\ "C"\ \{\ \dots \ \}
  2. 函数签名 $\text{fn}\ \text{strlen}(s\ast_{\text{const}} \text{c\_char}) \to \text{usize}$：strlen 接收一个指向字节串的指针，返回无符号整数。
    s:∗constc_char→usize\displaystyle s: \ast_{\text{const}} \text{c\_char} \to \text{usize}
  3. 调用安全性因为 C 函数可能读写任意内存，调用它必须放置于 unsafe 上下文，且传入指针必须指向有效的 C 字符串。
    valid(s)⇒strlen(s) safe\displaystyle \text{valid}(s) \Rightarrow \text{strlen}(s)\ \text{safe}

原则与审计：维修手册与收工检查单

老周给学徒定下两条铁律：一是能不动引擎盖就不动，二是每次掀开引擎盖都必须按手册记录。对应到 Rust，就是“最小化 unsafe”原则和“unsafe 注释规范”。如果你发现代码里到处是 unsafe，那通常不是性能好，而是设计差。

最小化 unsafe 的关键手段是收拢：把危险操作集中到少量函数内部，而不是散落在业务代码中。每写一个 unsafe 块，都应该配上 // SAFETY: 注释，说明为什么这里是安全的、调用者需要满足什么条件。这样当团队做 audit（审计）时，只需要审查这几个点，而不是全项目搜索。许多优秀库的审计，就是在几十行 SAFETY: ... 注释上逐字推敲。

老周打烊前会拿着检查单在车间转一圈：工具箱锁好、引擎盖盖严、公共台面清理干净。Rust 工程师也应该给自己的 unsafe 做同样的事——写完不等于安全，审计通过才算真的安全。

min⁡∑iunsafei,s.t. 功能需求\displaystyle \min \sum_{i} \text{unsafe}_i, \quad \text{s.t.}\ \text{功能需求}
该式表达了优化目标：在满足功能的约束下，尽可能减少 unsafe 出现的总数，让每个 unsafe 都可被充分审核。
  1. 最小化目标 $\min \sum_i \text{unsafe}_i$将全项目 unsafe 的出现次数作为成本，尽可能压到最低。
    min⁡∑iunsafei\displaystyle \min \sum_{i} \text{unsafe}_i
  2. 约束条件 $\text{s.t.}\ \text{功能需求}$最小化不能以牺牲必要功能为代价，该用 FFI 或底层接口时还是得用。
    s.t. 功能需求\displaystyle \text{s.t.}\ \text{功能需求}
  3. 可审计性每个 unsafe 块必须配套 SAFETY 注释，说明不变量与前提，使审计人员能一一行验证。
    unsafei⇒SAFETY 注释\displaystyle \text{unsafe}_i \Rightarrow \text{SAFETY}\ \text{注释}

AI 应用场景

高性能解析器中的裸指针跳过检查

阶段：数据预处理与高性能推理优化

解决的问题：AI 框架加载模型权重时，逐元素边界检查会带来可观的性能开销。传统 safe Rust 每次数组访问都有索引检查，在解析大模型文件、张量切片时拖慢速度。

具体案例：某推理引擎在反序列化模型权重时，先用 unsafe 从切片中获取裸指针，再按块批量读取浮点数。由于事先已验证缓冲区长度足够，后续循环不再需要逐次检查边界。测试显示，关键路径耗时降低了约 20%。

FFI 调用 C 库实现加速算子

阶段：算法集成与异构计算调度

解决的问题：大部分 AI 算子库（如 BLAS、LAPACK、OpenCV）由 C/C++ 编写，Rust 侧需要安全地调用这些底层库，同时避免重复造轮子。

具体案例：一个 Rust 实现的向量检索服务，通过 extern "C" 链接 CUDA 的 C 接口，将特征向量距离计算交给 GPU 执行。Rust 端把矩阵指针传给 C 函数，并负责记录内存释放时机；所有 unsafe 调用被封装在一个 cuda_ops 模块中，业务层只看到安全函数。

嵌入式 AI 模型中的寄存器映射

阶段：端侧部署与硬件抽象

解决的问题：在嵌入式设备（如 Cortex-M 芯片）上跑 AI 模型时，需要直接读写外设寄存器地址。普通 Rust 代码不允许直接操作任意内存地址，必须使用 unsafe 映射固定地址。

具体案例：一个端侧人脸检测项目，用 unsafe 把摄像头 DMA 缓冲区地址包装成 &mut [u8]，在固定内存地址上直接读写图像帧，避免数据拷贝。通过安全抽象封装后，上层算法工程师完全感知不到寄存器操作。

Python 演示

python29 行
import ctypes # 用 ctypes 模拟 Rust 的 extern "C" 声明# 在 Rust 中这等价于:# extern "C" { fn strlen(s: *const c_char) -> usize; }libc = ctypes.CDLL("libc.so.6")libc.strlen.argtypes = [ctypes.c_char_p]libc.strlen.restype = ctypes.c_size_t  def to_c_string(s: str) -> bytes:    # 构造 C 字符串，等价于 Rust 的 CString::new(s).unwrap()    return s.encode("utf-8") + b"\x00"  def safe_strlen(s: str) -> int:    # 安全抽象封装：把"FFI 调用"藏在普通函数后面    raw = to_c_string(s)    return libc.strlen(raw)  def main():    tests = ["hello", "rust", "", "unsafe ffi"]    for t in tests:        print(f"strlen({t!r}) = {safe_strlen(t)}")  if __name__ == "__main__":    main()
目的：用 Python 的 ctypes 模拟 Rust FFI 流程——加载 C 库、声明函数签名、构造 C 字符串指针、调用外部函数，最后用安全函数封装底层细节。
  1. libc = ctypes.CDLL("libc.so.6")加载 C 标准库，等价于 Rust 链接 libc 系统库。
  2. libc.strlen.argtypes = [ctypes.c_char_p]声明参数类型为字符指针，对应 Rust 的 *const c_char。
  3. libc.strlen.restype = ctypes.c_size_t声明返回类型为无符号整数，对应 Rust 的 usize。
  4. def to_c_string(s: str) -> bytes:把 Python 字符串编码成带 \0 结尾的 C 字符串，等价于 CString::new。
  5. def safe_strlen(s: str) -> int:安全抽象封装：外部只调用这个函数，不接触底层指针。
  6. raw = to_c_string(s)构造指针指向的底层缓冲区，这一步对应 FFI 前必须保证内存有效。
  7. libc.strlen(raw)真正调用 C 函数，对应 Rust 中要放在 unsafe 块里的那一步。

常见误区

误区进入 `unsafe { }` 之后，编译器就不再检查我的代码了，我可以随意操作内存、无视借用规则。

正解unsafe 只额外开放五种操作，借用检查器和类型检查依然生效。比如你在 unsafe 块里写 &mut a 和 &a 同时存在，编译器照样拒绝。它是在“安全检查之外增加权限”，不是“关闭所有检查”。

为何常见：许多初学者把 unsafe 类比成 C++ 的裸指针自由区，以为进入后无需遵守任何规则，因此低估了编译器的持续约束力。

误区`*const T` 不就是 `&T` 吗？反正都能访问值，用哪个都行。

正解引用永远保证指向有效内存，并且有生命周期约束；裸指针只是一个地址，可能悬空、可能未对齐、可能为空。把裸指针当引用用，等于摘下安全气囊开车，只是“暂时没问题”，不代表“没有问题”。

为何常见：从 C/C++ 转 Rust 的人习惯把地址和引用混为一谈，忽略了 Rust 引用背后的编译期保证。

误区我在 `unsafe` 块里读写 `static mut`，代码能编译通过，那就说明这样是安全的。

正解编译通过只表示你符合语法，不代表运行时没有数据竞争。两个线程同时执行各自的 unsafe 块去写同一个静态变量，仍然是未定义行为。必须用互斥锁、原子类型或把静态变量改为不可变加内部可变性，才能真正安全。

为何常见：初学者把 unsafe 当作“安全通行证”，看到编译通过就放松警惕，忽略了内存模型层面的并发风险。

误区能写 unsafe fn 就算入门了，unsafe trait 只是声明一下而已，没什么复杂的。

正解unsafe trait 的定义和实现都很简单，难的是背后的语义承诺。比如实现 Send 告诉编译器“我的类型可以跨线程传递”，如果你内部持有裸指针且没有同步保护，多线程运行就会出现未定义行为。一句话的事，责任重于泰山。

为何常见：trait 实现看起来只有几行代码，人们容易低估“类型契约”对编译器全局推理的影响。

误区我调 C 库、做底层操作，所以我的代码里到处都是 `unsafe` 是正常的。

正解工程实践恰恰相反：unsafe 应该被收拢到少数几个内部函数中，对外暴露安全接口。比如 sqlite crate 内部充斥着 FFI unsafe，但用户调用它的高级 API 时完全不需要写 unsafe。滥用 unsafe 只会让审计成本爆炸。

为何常见：很多人从“能跑就行”的视角出发，缺乏安全封装意识，于是 unsafe 像病毒一样扩散到整个代码库。

面试题

Q1. 在 Rust 中，下列哪项操作必须放进 unsafe 上下文？

单选题 · easy

  • A.解引用裸指针← 正确答案
  • B.声明一个枚举
  • C.使用普通引用
  • D.匹配模式分支

答案：A。解引用裸指针是五种 unsafe 操作之一，因为编译器无法验证指针有效性。声明枚举、使用引用、模式匹配都是安全 Rust 的语法，不需要 unsafe。

Q2. unsafe 块不会关闭以下哪项检查？

单选题 · easy

  • A.借用检查器← 正确答案
  • B.索引越界检查
  • C.算术溢出检查
  • D.空指针检查

答案：A。unsafe 只额外放开五种操作，借用检查和类型检查照常生效。索引越界、算术溢出都不是 unsafe 开放的内容，通常只需调试断言或运行时处理。

Q3. FFI 在 Rust 中的中文含义是什么？

单选题 · easy

  • A.外部函数接口← 正确答案
  • B.快速文件索引
  • C.全量函数调用
  • D.形式功能交互

答案：A。FFI 全称 Foreign Function Interface，指调用其他语言函数的能力。其余选项是干扰项，与跨语言调用的语义无关。

Q4. extern "C" 声明块的主要作用是什么？

单选题 · easy

  • A.声明外部 C 函数← 正确答案
  • B.开启垃圾回收
  • C.关闭所有检查
  • D.创建新的线程

答案：A。extern "C" 告诉 Rust 编译器，这里有一批遵循 C 调用约定的外部函数，需要按 C ABI 进行链接和调用。垃圾回收、关闭检查、创建线程都与它无关。

Q5. 裸指针 *mut T 与可变引用 &mut T 最本质的区别是什么？

单选题 · mid

  • A.裸指针可不指向有效内存← 正确答案
  • B.引用会移动变量所有权
  • C.裸指针会自动解引用
  • D.引用必须指向堆内存

答案：A。裸指针只是一个地址值，不需要保证指向有效内存，也没有生命周期和别名约束；可变引用则必须指向有效内存、拥有独占性且有编译器验证的生命周期。引用不会移动所有权，裸指针不会自动解引用，引用可以指向栈内存。

Q6. 为什么对 static mut 变量的读写必须放在 unsafe 中？

单选题 · mid

  • A.可能引发数据竞争← 正确答案
  • B.会导致栈空间溢出
  • C.会让编译器无法推断类型
  • D.会阻塞操作系统调度

答案：A。static mut 是全局共享的可变状态，多个线程并发读写可能产生数据竞争，进而导致未定义行为。编译器无法自动判断访问时机，所以需要程序员用 unsafe 标记责任，并自行加锁或使用原子类型。

Q7. 关于 unsafe trait，以下哪些说法是正确的？

多选题 · mid

  • A.实现者需要自己保证契约成立← 正确答案
  • B.编译器无法自动验证其安全性← 正确答案
  • C.常见例子包括 Send 和 Sync 的手动实现← 正确答案
  • D.它比 unsafe 函数更危险且禁止使用

答案：ABC。unsafe trait 把安全责任交给实现者，编译器不做自动验证。Send、Sync 是典型用例。D 错在“禁止使用”——Rust 允许使用 unsafe trait，只是要求谨慎背书。

Q8. 解引用一个悬空裸指针会产生什么行为？

单选题 · hard

  • A.未定义行为← 正确答案
  • B.必定引发段错误
  • C.编译器必定报错
  • D.自动被替换为空指针

答案：A。悬空指针意味着指针指向的内存已释放或无效，解引用它属于未定义行为。后果可能是崩溃，也可能碰巧读到脏数据，甚至被编译器优化成任意指令，所以绝不能依赖“一定会崩”。

Q9. 以下哪些属于安全抽象封装的核心做法？

多选题 · hard

  • A.把 unsafe 藏进私有函数← 正确答案
  • B.公共 API 保持安全签名← 正确答案
  • C.用不变量维护数据有效性← 正确答案
  • D.在模块内散落大量 unsafe

答案：ABC。安全抽象要求 unsafe 集中在私有实现中，公共接口不暴露危险操作，并用不变量保证数据始终合法。D 是反模式：unsafe 散落各处会大幅提高审计难度，违背最小化原则。

Q10. 关于可变静态变量与并发，哪些说法是正确的？

多选题 · extreme

  • A.直接多线程读写会数据竞争← 正确答案
  • B.用 Mutex 包一层可避免竞争← 正确答案
  • C.原子类型能安全地进行读写← 正确答案
  • D.在 unsafe 块内加锁就自动消除竞争

答案：ABC。static mut 的读写本质是全局共享可变状态，直接并发必然竞争。用 Mutex 或原子类型包装后，所有访问都走同步原语，可避免竞争。D 错在“自动”二字：若加锁不一致，只在某个 unsafe 块内加锁仍可能与其他不加锁的访问竞争。