unsafe 简介

圣人论迹不论心，论心世上无圣人，对于编程语言而言，亦是如此。

虽然在本章之前，我们学到的代码都是在编译期就得到了 Rust 的安全保障，但是在其内心深处也隐藏了一些阴暗面，在这些阴暗面里，内存安全就存在一些变数了：当不娴熟的开发者接触到这些阴暗面，就可能写出不安全的代码，因此我们称这种代码为 unsafe 代码块。

为何会有 unsafe

几乎每个语言都有 unsafe 关键字，但 Rust 语言使用 unsafe 的原因可能与其它编程语言还有所不同。

说来尴尬，unsafe 的存在主要是因为 Rust 的静态检查太强了，但是强就算了，它还很保守，这就会导致当编译器在分析代码时，一些正确代码会因为编译器无法分析出它的所有正确性，结果将这段代码拒绝，导致编译错误。

这种保守的选择确实也没有错，毕竟安全就是要防微杜渐，但是对于使用者来说，就不是那么愉快的事了，特别是当配合 Rust 的所有权系统一起使用时，有个别问题是真的棘手和难以解决。

举个例子，在之前的自引用章节中，我们就提到了相关的编译检查是很难绕过的，如果想要绕过，最常用的方法之一就是使用 unsafe 和 Pin。

好在，当遇到这些情况时，我们可以使用 unsafe 来解决。此时，你需要替代编译器的部分职责对 unsafe 代码的正确性负责，例如在正常代码中不可能遇到的空指针解引用问题在 unsafe 中就可能会遇到，我们就需要自己来处理好这些类似的问题。

至于 unsafe 存在的另一个原因就是：它必须要存在。原因是计算机底层的一些硬件就是不安全的，如果 Rust 只允许你做安全的操作，那一些任务就无法完成，换句话说，我们还怎么跟 C++ 干架？

Rust 的一个主要定位就是系统编程，众所周知，系统编程就是底层编程，往往需要直接跟操作系统打交道，甚至于去实现一个操作系统。而为了实现底层系统编程，unsafe 就是必不可少的。

在了解了为何会有 unsafe 后，我们再来看看，除了这些必要性，unsafe 还能给我们带来哪些超能力。

使用 unsafe 非常简单，只要用将对应的代码块标记下即可:

fn main() {
    let mut num = 5;

    let r1 = &num as *const i32;

    unsafe {
        println!("r1 is: {}", *r1);
    }
}

上面代码中, r1 是一个原生指针(又称裸指针，raw pointer)，由于它具有破坏 Rust 内存安全的潜力，因此只能在 unsafe 代码块中使用，如果你去掉 unsafe {}，编译器会立刻报错。

言归正传， unsafe 能赋予我们 5 种超能力，这些能力在安全的 Rust 代码中是无法获取的：

在本章中，我们将着重讲解原生指针和 FFI 的使用。

曾经在 reddit 上有一个讨论还挺热闹的，是关于 unsafe 的命名是否合适，总之公有公理，婆有婆理，但有一点是不可否认的：虽然名称自带不安全，但是 Rust 依然提供了强大的安全支撑。

首先，unsafe 并不能绕过 Rust 的借用检查，也不能关闭任何 Rust 的安全检查规则，例如当你在 unsafe 中使用引用时，该有的检查一样都不会少。

因此 unsafe 能给大家提供的也仅仅是之前的 5 种超能力，在使用这5种能力时，编译器才不会进行内存安全方面的检查，最典型的就是使用原生指针(引用和原生指针有很大的区别)。

在网上充斥着这样的言论：千万不要使用 unsafe，因为它不安全，甚至有些库会以没有 unsafe 代码作为噱头来吸引用户。事实上，大可不必，如果按照这个标准，Rust 的标准库也将不复存在！

Rust 中的 unsafe 其实没有那么可怕，虽然听上去很不安全，但是实际上 Rust 依然提供了很多机制来帮我们提升了安全性，因此不必像对待 Go 语言的 unsafe 那样去畏惧于使用Rust中的 unsafe 。

大致使用原则总结如下：没必要用时，就不要用，当有必要用时，就大胆用，但是尽量控制好边界，让 unsafe 的范围尽可能小。

unsafe 不安全，但是该用的时候就要用，在一些时候，它能帮助我们大幅降低代码实现的成本。

而作为使用者，你的水平决定了 unsafe 到底有多不安全，因此你需要在 unsafe 中小心谨慎地去访问内存。

即使做到小心谨慎，依然会有出错的可能性，但是 unsafe 语句块决定了：就算内存访问出错了，你也能立刻意识到，错误是在 unsafe 代码块中，而不花大量时间像无头苍蝇一样去寻找问题所在。

正因为此，写代码时要尽量控制好 unsafe 的边界大小，越小的 unsafe 越会我们在未来感谢自己当初的选择。

除了控制边界大小，另一个很常用的方式就是在 unsafe 代码块外包裹一层 safe 的 API，例如一个函数声明为 safe 的，然后在其内部有一块儿是 unsafe 代码。

忍不住抱怨一句，内存安全方面的 bug ，是真心难查！