一句话总结： 解释 Rust 中的 unsafe 关键字，它允许开发者绕过编译时安全检查，并强调在使用 unsafe 代码时必须遵守的五大不变量。
引言：unsafe 并非“不安全”，而是“开发者负责安全”

Rust 以其卓越的内存安全和线程安全保证而闻名，这主要得益于其强大的所有权系统和借用检查器，它们在编译时捕获了大量潜在的错误。然而，在某些特定场景下，为了实现极致的性能、与外部语言交互（FFI）或直接操作底层硬件，Rust 提供了 unsafe 关键字。

对于初学者来说，unsafe 这个词可能会引起恐慌，让人误以为它会完全关闭 Rust 的所有安全保障，使代码变得像 C/C++ 一样危险。但事实并非如此。unsafe 并非意味着“不安全”，而是意味着**“开发者负责安全”**。当使用 unsafe 关键字时，你是在向编译器承诺：你理解你正在做什么，并且你将手动维护 Rust 通常在编译时自动强制执行的内存安全和并发安全不变量。

unsafe 块并不会禁用借用检查器或类型系统。它只是允许你执行五种额外的操作，这些操作在安全 Rust 中是被禁止的，因为编译器无法独立验证它们的正确性。这些操作如果使用不当，确实可能导致未定义行为（Undefined Behavior, UB），这是 Rust 极力避免的。因此，理解 unsafe 的真正含义和其带来的责任至关重要。它不是一个逃避 Rust 规则的后门，而是一个精心设计的工具，用于在必要时扩展 Rust 的能力，同时将安全保证的责任从编译器转移到开发者身上。

unsafe 的作用：扩展 Rust 的能力

unsafe 关键字允许开发者执行以下五种在安全 Rust 中被禁止的操作。这些操作之所以被标记为 unsafe，是因为它们可能在不正确使用时导致未定义行为。

1.解引用裸指针（Dereferencing Raw Pointers）：

  • 在安全 Rust 中，你只能使用引用（& 和 &mut），它们由借用检查器严格管理，保证了有效性和生命周期。
  • unsafe 允许你使用裸指针（Raw Pointers），即 *const T（不可变裸指针）和 *mut T（可变裸指针）。裸指针类似于 C/C++ 中的指针，它们没有生命周期，也没有借用检查器的保证。
  • 解引用裸指针（即通过 *ptr 访问其指向的值）是一个 unsafe 操作，因为编译器无法验证该指针是否有效、是否为空、是否指向已释放的内存，或者是否存在数据竞争。
fn main() {
    let mut num = 5;
    let r1 = &num as *const i32; // 创建不可变裸指针
    let r2 = &mut num as *mut i32; // 创建可变裸指针

    unsafe {
        println!("r1 指向的值: {}", *r1); // 解引用裸指针，unsafe
        *r2 = 6; // 通过裸指针修改值，unsafe
        println!("r2 修改后的值: {}", *r2);
    }
}

2.调用 unsafe 函数或方法（Calling unsafe Functions or Methods）：

  • 有些函数或方法被标记为 unsafe，这意味着它们有特定的前置条件（preconditions），调用者必须确保这些条件得到满足，否则可能导致未定义行为。
  • 例如，std::slice::get_unchecked 函数允许你访问切片中指定索引的元素，而不进行边界检查。如果索引超出范围，调用它将导致未定义行为。
fn main() {
    let mut vec = vec![1, 2, 3, 4, 5];
    let index = 10; // 越界索引

    // 安全 Rust 会报错或panic
    // println!("{}", vec[index]); // panic!
    // println!("{:?}", vec.get(index)); // None

    unsafe {
        // 调用 unsafe 函数，开发者必须保证 index 在有效范围内
        // 如果 index 越界，这里将导致未定义行为
        let value = vec.get_unchecked(index);
        println!("通过 get_unchecked 访问的值: {}", value); // 可能会打印垃圾值或崩溃
    }
}

3.访问或修改可变静态变量（Accessing or Modifying Mutable Static Variables）：

  • Rust 默认的 static 变量是不可变的，或者如果可变，则需要 Mutex 等同步机制来安全访问。
  • static mut 变量是全局可变的静态变量，但它们的访问和修改操作是 unsafe 的。这是因为多个线程可以同时访问和修改 static mut 变量，从而导致数据竞争，而编译器无法在编译时强制执行同步。
static mut COUNTER: i32 = 0; // 可变静态变量

fn main() {
    unsafe {
        COUNTER += 1; // 访问和修改 static mut 变量，unsafe
        println!("计数器: {}", COUNTER);
    }
}

4.实现 unsafe Trait（Implementing unsafe Trait）：

  • 某些 Trait 本身被标记为 unsafe，这意味着它们的实现者必须手动维护特定的不变量（invariants），以确保类型在使用该 Trait 时是安全的。
  • 例如，Send 和 Sync Trait 虽然是自动实现的，但它们在概念上是 unsafe 的：如果你手动实现它们（通常通过 #[allow(unsafe_code)] 和 unsafe impl），你必须确保你的类型确实可以安全地在线程间移动或共享引用。如果违反了这些不变量，将导致数据竞争或其他并发问题。
// 假设我们有一个自定义的UnsafeTrait
unsafe trait MyUnsafeTrait {
    // 这个trait可能有一些隐式的不变量，需要实现者保证
    fn do_something_unsafe(&self);
}

struct MyStruct;

// 实现 unsafe trait 必须在 unsafe 块中
unsafe impl MyUnsafeTrait for MyStruct {
    fn do_something_unsafe(&self) {
        println!("执行了 unsafe trait 的方法");
        // 在这里，开发者必须确保 do_something_unsafe 的实现是安全的
    }
}

fn main() {
    let s = MyStruct;
    s.do_something_unsafe();
}

5.访问 union 的字段（Accessing union Fields）：

  • union 是一种 C 语言风格的类型，它允许在同一内存位置存储不同类型的值。在任何给定时间，union 只能存储其中一个字段的值。
  • 访问 union 的字段是 unsafe 的，因为编译器无法知道当前 union 中存储的是哪个类型的值。如果你尝试读取一个与当前存储类型不匹配的字段，将导致未定义行为。
union MyUnion {
    f1: u32,
    f2: f32,
}

fn main() {
    let u = MyUnion { f1: 123 }; // 存储 u32 类型

    unsafe {
        println!("从 f1 读取: {}", u.f1); // 安全读取
        // 尝试从 f2 读取，虽然编译通过，但可能导致未定义行为，因为实际存储的是 u32
        println!("从 f2 读取: {}", u.f2);
    }
}
unsafe 的五大不变量（Undefined Behavior）：开发者必须遵守的规则

当你在 unsafe 块中编写代码时，你是在向编译器承诺，你将手动维护 Rust 的核心安全不变量。如果违反了这些不变量，你的程序将进入**未定义行为（Undefined Behavior, UB）**的状态。UB 是最危险的错误，因为它可能导致程序崩溃、数据损坏、安全漏洞，甚至在某些情况下，程序看似正常运行，但结果却是错误的，且难以追踪。

以下是使用 unsafe 时必须避免的五大类未定义行为：

  1. 解引用空指针或悬垂指针（Dereferencing Null or Dangling Pointers）：

    • 空指针： 指向内存地址 0 的指针。解引用空指针几乎总是导致程序崩溃。
    • 悬垂指针： 指向已被释放或不再有效的内存区域的指针。解引用悬垂指针可能导致访问垃圾数据、修改不属于你的内存，或者在内存被重新分配后导致数据损坏。
    • 开发者责任： 确保所有解引用的裸指针都是有效的，并且指向的内存是已分配且未被释放的。

  2. 数据竞争（Data Races）：

    • 当多个线程同时访问同一块内存，并且至少有一个访问是写入操作，而这些访问之间缺乏适当的同步机制时，就会发生数据竞争。
    • 数据竞争是并发编程中最常见的 UB 来源，它会导致程序行为不可预测，产生错误的结果。
    • 开发者责任： 在 unsafe 代码中处理共享可变状态时，必须使用 Mutex、RwLock、原子操作或其他同步原语来确保线程安全。

  3. 违反内存安全（如缓冲区溢出）（Memory Safety Violations like Buffer Overflows）：

    • 缓冲区溢出/下溢： 尝试读写超出分配给某个数据结构（如数组、切片）的内存边界。这可能覆盖相邻的内存，导致数据损坏或程序崩溃。
    • 越界访问： 访问一个无效的内存地址。
    • 开发者责任： 确保所有内存访问都在合法边界内，不读写未分配或不属于你的内存。

  4. 未初始化的内存（Uninitialized Memory）：

    • 读取尚未被写入任何有效值的内存区域。在 Rust 中，未初始化的内存被认为是无效的，读取它会导致 UB。
    • 安全 Rust 保证所有变量在使用前都已初始化。但在 unsafe 代码中，你可以直接操作原始内存，因此必须确保你读取的内存已经被正确初始化。
    • 开发者责任： 在读取任何内存之前，确保该内存已经被写入了有效的数据。

  5. 违反 Trait 不变量（Violating Trait Invariants）：

    • 当你实现一个 Trait 时，该 Trait 可能有一些隐式的或显式的“不变量”或“契约”，这些是其正确行为所必需的。
    • 对于 unsafe Trait（如 Send 和 Sync），如果你手动实现它们，但你的类型实际上不满足其线程安全要求，那么你将引入 UB。
    • 开发者责任： 深入理解所实现 Trait 的所有不变量，并确保你的实现严格遵守这些不变量。

何时需要 unsafe：必要场景

尽管 unsafe 带来了额外的责任，但在某些特定场景下，它是不可或缺的：

1.FFI（与 C/C++ 交互）（Foreign Function Interface）：

  • Rust 经常需要与用其他语言（尤其是 C 或 C++）编写的库进行交互。这些外部函数通常不遵循 Rust 的内存安全规则，可能接受裸指针、返回裸指针，或者在内部执行不安全的操作。
  • 为了调用这些外部函数，你必须使用 extern "C" 块来声明它们，并且调用这些函数本身通常是 unsafe 的，因为 Rust 编译器无法验证外部代码的安全性。
extern "C" {
    // 声明一个外部 C 函数，它接受一个指针并返回一个整数
    fn abs(input: i32) -> i32;
    fn my_c_function(ptr: *mut i32);
}

fn main() {
    unsafe {
        // 调用外部 C 函数，unsafe
        println!("C 语言的 abs(-3) 是: {}", abs(-3));

        let mut value = 10;
        let ptr = &mut value as *mut i32;
        my_c_function(ptr); // 调用外部 C 函数，unsafe
        println!("C 函数修改后的值: {}", value);
    }
}

2.操作系统底层调用（Operating System Low-Level Calls）：

  • 当需要直接与操作系统 API 交互时（例如，进行内存映射、文件系统操作、设备驱动开发等），往往需要使用 unsafe 来调用底层的系统调用，这些调用通常涉及裸指针和不安全的内存操作。
  • Rust 的标准库本身在实现文件 I/O、网络通信等功能时，内部也大量使用了 unsafe 来封装底层的系统调用。

3.实现高性能数据结构（Implementing High-Performance Data Structures）：

  • 为了实现某些高度优化的数据结构（如自定义的 Vec、HashMap、链表、双端队列等），有时需要绕过 Rust 的借用检查器，直接管理内存布局和指针。
  • 例如，在实现一个没有运行时开销的链表时，可能需要手动管理节点之间的指针，这通常涉及裸指针的解引用和内存分配/释放，这些都是 unsafe 操作。
  • 在这种情况下，unsafe 代码被用来实现内部逻辑，但其外部 API 仍然是安全的。
unsafe 代码的封装与抽象：创建安全抽象

在 Rust 中使用 unsafe 的最佳实践是将其**封装在安全的抽象（Safe Abstraction）**中。这意味着 unsafe 代码应该被限制在尽可能小的模块或函数内部，并提供一个完全安全的公共 API。

  • 目标： 即使 unsafe 内部逻辑复杂且可能出错，外部用户也无法通过公共 API 导致未定义行为。
  • 方法：
    1. 隔离 unsafe： 将所有 unsafe 代码集中在一个私有模块或函数中。
    2. 严格的前置条件： 确保 unsafe 代码的所有前置条件都由外部安全 API 强制执行或验证。
    3. 验证不变量： 确保 unsafe 代码在执行后，所有数据结构的不变量都得到维护。
    4. 文档： 详细记录 unsafe 代码的假设、前置条件和后置条件，以及它如何维护安全不变量。
    5. 测试： 对 unsafe 代码进行彻底的单元测试和模糊测试，以确保其在各种情况下都能正确运行。

例如，Rust 标准库中的 Vec 类型内部就大量使用了 unsafe 来管理其底层数组的内存分配和元素移动。然而，Vec 的公共 API（如 push、pop、get 等）是完全安全的，用户无法通过这些方法导致内存错误。这就是一个成功的安全抽象的典范。

// 这是一个简化的例子，展示如何封装 unsafe
// 实际的 Vec 实现要复杂得多
struct MyVec<T> {
    ptr: *mut T,
    len: usize,
    capacity: usize,
}

impl<T> MyVec<T> {
    fn new() -> Self {
        MyVec {
            ptr: std::ptr::null_mut(),
            len: 0,
            capacity: 0,
        }
    }

    // 这是一个安全的公共方法
    fn push(&mut self, item: T) {
        if self.len == self.capacity {
            self.grow(); // 内部可能调用 unsafe
        }
        unsafe {
            // 将 item 写入到 ptr + len 的位置
            std::ptr::write(self.ptr.add(self.len), item);
            self.len += 1;
        }
    }

    // 这是一个私有的辅助方法，内部包含 unsafe
    fn grow(&mut self) {
        let new_capacity = if self.capacity == 0 { 1 } else { self.capacity * 2 };
        let new_ptr = unsafe {
            // 重新分配内存，这是一个 unsafe 操作
            let layout = std::alloc::Layout::array::<T>(new_capacity).unwrap();
            let new_ptr = std::alloc::alloc(layout) as *mut T;

            // 将旧数据复制到新内存，这也是 unsafe
            std::ptr::copy_nonoverlapping(self.ptr, new_ptr, self.len);

            // 释放旧内存，unsafe
            if !self.ptr.is_null() {
                let old_layout = std::alloc::Layout::array::<T>(self.capacity).unwrap();
                std::alloc::dealloc(self.ptr as *mut u8, old_layout);
            }
            new_ptr
        };
        self.ptr = new_ptr;
        self.capacity = new_capacity;
    }
}

impl<T> Drop for MyVec<T> {
    fn drop(&mut self) {
        if !self.ptr.is_null() {
            unsafe {
                // 释放所有元素
                for i in 0..self.len {
                    std::ptr::drop_in_place(self.ptr.add(i));
                }
                // 释放底层内存
                let layout = std::alloc::Layout::array::<T>(self.capacity).unwrap();
                std::alloc::dealloc(self.ptr as *mut u8, layout);
            }
        }
    }
}

fn main() {
    let mut my_vec = MyVec::new();
    my_vec.push(10);
    my_vec.push(20);
    // 用户通过安全的 API 使用 MyVec，无需关心内部的 unsafe
    println!("MyVec 长度: {}", my_vec.len);
}

在这个简化版的 MyVec 中，push 方法是安全的，但它内部调用了 grow 方法，而 grow 方法以及 Drop 实现中包含了内存分配、复制和释放的 unsafe 操作。通过这种封装，用户可以安全地使用 MyVec，而无需直接接触 unsafe 代码。

结论：unsafe 是 Rust 的强大工具，但需谨慎使用，并确保其内部逻辑的绝对正确性

unsafe Rust 是 Rust 语言不可或缺的一部分，它赋予了 Rust 极高的灵活性和性能，使其能够胜任系统编程、嵌入式开发以及与现有 C/C++ 代码库集成等任务。然而，这种能力伴随着巨大的责任。

使用 unsafe 关键字，你是在向编译器承诺，你将手动维护 Rust 通常在编译时自动强制执行的内存安全和并发安全不变量。这意味着你必须对代码的每一个细节、每一个潜在的执行路径都了如指掌，并确保它在所有情况下都不会导致未定义行为。

因此，在使用 unsafe 时，务必遵循以下原则：

  • 最小化 unsafe 范围： 尽可能将 unsafe 代码限制在最小的块或函数中。
  • 创建安全抽象： 始终努力将 unsafe 代码封装在提供安全公共 API 的模块或类型中。
  • 彻底的文档： 详细记录 unsafe 代码的所有假设、前置条件、后置条件以及它如何维护安全不变量。
  • 严格的测试： 对 unsafe 代码进行比安全代码更严格、更全面的测试，包括单元测试、集成测试和模糊测试。
  • 代码审查： 让经验丰富的 Rust 开发者审查你的 unsafe 代码。

unsafe 并非 Rust 的弱点，而是其力量的体现。它允许 Rust 在提供高级安全保证的同时，依然能够深入底层，实现极致的控制和性能。正确地使用 unsafe，是成为一名真正熟练的 Rust 程序员的关键一步。它要求开发者不仅理解 Rust 的语法，更要深刻理解其背后的内存模型和安全哲学。

# rust # 安全 # 开发语言
Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

从一张商品图到正式上架：实测店匠 Shoplazza Athena，AI Agent 不只是聊天框

avatar AI Agent技术社区
cover

我测试了一个0.9B模型，它竟然能自动区分多人讲话）

avatar AI Agent技术社区
cover

【AI Agent】《2026年9月 AI Agent全栈开发技术选型专项面试宝典》

avatar AI Agent技术社区