当我们谈论 Rust 的内存安全时，借用检查器（borrow checker）是一个绕不开的核心组件。自 2012 年 Rust 1.0 正式发布以来，借用检查器一直是这门语言最具辨识度的特性之一。然而，围绕借用检查器的实现方式，学术界和工业界一直在探索各种可能性。本文将深入探讨一种与 Rust 当前实现截然不同的借用检查技术路径：绕过传统类型系统，通过别名追踪与能力推断来实现内存安全。
传统借用检查的类型系统依赖
在 Rust 的主流实现中，借用检查器与类型系统是深度耦合的。当我们写 &'a i32 时，生命周期参数 'a 实际上对应于程序源代码或控制流图中的某个区域。编译器利用这些生命周期信息来执行「一个可变借用或多个不可变借用」的规则。这种依赖关系意味着借用检查并非独立于语法分析的独立通道，而是需要依赖类型层面的引用使用位置和相互关系信息。
从实现角度来看，这种紧密耦合带来了几个显著的优势。类型系统提供了一种统一的框架来表达借用的约束，生命周期参数可以参与到子类型关系的推导中，编译器能够生成相对友好的错误信息。然而，这种设计也引入了一些局限性。首先，类型系统必须足够复杂才能精确地描述借用的约束，这对于语言的学习曲线是一个挑战。其次，某些在语义上安全的程序可能因为类型系统的近似表达能力而被拒绝，需要开发者编写复杂的显式注解来帮助编译器理解代码的意图。
基于别名的形式化方法
2018 年，Nicholas Matsakis 在 Rust All Hands 会议上提出了一种替代性的借用检查器形式化方法，其核心思想是将区域（region）重新定义为贷款（loan）的集合，而非程序点。在传统的 NLL（Non-Lexical Lifetimes）方案中，生命周期最终对应于控制流图中的某个位置；而在新方案中，区域被理解为一组借表达式的集合。例如，对于 &x 或 &mut v 这样的借用表达式，每个借用都会产生一个唯一的贷款标识符，而区域则对应于这些贷款的集合。
这种形式化的一个关键优势在于其数学上的优雅性。如果一个引用 r 的类型是 &'a i32，那么使 'a 中任何贷款的条款失效都会使 r 失效。这种视角使得借用检查的问题可以转化为一个纯粹的约束传播问题。Matsakis 使用 Datalog 来描述这种分析，其核心思想是通过一组逻辑规则来推导「区域 R 需要贷款 L 在点 P 时生效」这一关系。
具体来说，这个系统包含几个关键的关系定义。subset(R1, R2, P) 表示在点 P 处，R1: R2 的约束必须成立。requires(R, L, P) 表示区域 R 要求贷款 L 在点 P 时被维护。invalidates(P, L) 表示在点 P 处对贷款 L 进行了非法访问。最后，error(P) 在点 P 处存在一个活跃的贷款被失效时触发。整个分析过程从类型检查器产生的「基础子集」关系开始，然后通过 Datalog 规则在控制流图上传播这些约束，并考虑区域的活跃性。
这种基于别名的方法已经在原型中得到了实现，并通过了对完整 NLL 测试套件的测试。更重要的是，它能够处理一些当前 NLL 分析无法接受的程序，例如经典的 issue #47680 中的循环变异模式。
动态类型语言中的借用检查
Jamie Brandon 在其博客中提出了一个更为激进的探索：在完全动态类型的语言中实现借用检查。他的项目 Zest 旨在结合动态类型系统的灵活性与静态类型系统的性能优势，而关键挑战之一就是如何在没有静态类型信息的情况下实现内存安全。
这个系统采用了一种运行时检查的策略。每个变量都关联一个引用计数，这个计数可以处于四种状态：当 ref_count == INT_MIN 时，表示该变量中的值已被移动；当计数为负数时，表示有多少借用引用指向这个值；当计数为零时，表示该变量可供借用或共享；当计数为正数时，表示有多少共享引用指向这个值。
对于每个借用或共享引用，系统存储三个关键信息：lease 表示引用是拥有的、借用的还是共享的；lender 表示从哪个变量借用，以及在引用被丢弃时需要递减谁的引用计数；owner 表示该值最初属于哪个变量，其生命周期决定了哪些值可以安全地写入这个引用。这种设计允许系统在运行时检测并防止所有的借用规则违反。
这种动态检查的开销是有限的。引用计数仅在创建、丢弃或复制引用时才会被修改。引用计数本身始终存储在栈上，因此对缓存的影响很小。由于引用计数从不在线程间共享，更新时不需要使用原子操作。关键的是，这些引用计数开销只在动态类型的函数帧中支付，静态类型的代码永远不需要看到它们。
能力推断：从类型到行为
无论是基于别名的静态分析还是动态类型的运行时检查，这些方法的共同点在于它们都试图从程序的结构中推断出「能力」，而不是依赖显式的类型注解。这种思路可以被称为「能力推断」（capability inference）。
在传统 Rust 中，开发者必须通过类型系统显式地表达意图：哪些引用是可变的，哪些是共享的，借用的生命周期有多长。而在新的范式下，编译器或运行时系统会分析程序的控制流和数据流，自动推断出这些约束。这种方法的好处是显而易见的：它降低了语言的语法负担，使得开发者可以更专注于业务逻辑而非类型注解。同时，它也使得将动态类型代码与静态类型代码混合成为可能，因为系统可以在运行时精确地知道哪些检查是必要的。
然而，能力推断也带来了新的挑战。由于约束不是显式表达的，错误信息可能更难理解。当一个借用规则被违反时，系统需要追溯这个约束是从哪里产生的，这在没有显式注解的情况下可能变得复杂。此外，推断算法的复杂度也是一个实际考虑因素，过度复杂的推断可能会导致编译时间显著增加。
工程实现的关键参数
对于希望实现类似系统的开发者，以下几个工程参数值得特别关注。
首先是引用计数的状态空间设计。在动态类型实现中，引用计数需要能够区分「已移动」「可借用」「有借用者」「可共享」「有共享者」等多种状态。使用有符号整数是一种常见的选择：将负数区间用于借用计数，正数区间用于共享计数，而特殊的最小值用于表示「已移动」。这种设计的优势在于每种安全检查都可以简化为单个整数比较。
其次是错误消息的精确性。当借用规则被违反时，能够准确定位违规的引用是提供良好用户体验的关键。在动态实现中，系统知道所有借用和共享引用都位于栈上，因此可以在错误发生时扫描栈来找到借用了被违规变量的确切位置。这种方法虽然需要额外的计算，但能够提供非常有价值的诊断信息。
第三是静态与动态代码的边界处理。当动态类型代码调用静态类型代码（或反之）时，需要确保静态类型的代码不会以破坏引用计数的方式使用引用。一种有效的策略是使用「跨栈调用」机制：在调用前将引用复制到新的栈帧，并修改其「来源」指向新栈上的虚拟借出者；调用返回后再更新原始借出者的引用计数。
与形式化验证的对比
值得注意的是，本文讨论的技术路径与 Verus 等形式化验证工具有着本质的不同。形式化验证试图在编译时证明程序的某些属性（如内存安全、函数式正确性）完全成立，这通常需要复杂的证明助手和额外的规范工作。而基于别名追踪和能力推断的方法则更加轻量级：它不试图证明代码「正确」，而是确保任何违反内存安全的操作都会在运行时被捕获，或者在静态分析中被拒绝。
这两种方法并非互斥。实际上，一个理想的安全系统可能会结合两者的优点：使用轻量级的借用检查来处理绝大多数常见情况，同时保留形式化验证的选项来处理关键任务代码。然而，对于那些希望在保证安全的同时保持开发效率的团队来说，理解借用检查的不同实现方式是有价值的。
结语
借用检查是 Rust 最具创新性的特性之一，但其当前实现并非唯一可能的选择。通过将区域重新解释为贷款的集合，我们可以在不依赖传统类型系统的情况下实现内存安全。通过运行时引用计数和活跃性追踪，动态类型语言也可以获得借用检查的保证。这些探索不仅有助于我们更好地理解借用检查的本质，也为未来编程语言的设计提供了有价值的参考。
资料来源：本文核心观点来自 Nicholas Matsakis 关于基于别名的借用检查器形式化研究（https://smallcultfollowing.com/babysteps/blog/2018/04/27/an-alias-based-formulation-of-the-borrow-checker/）以及 Jamie Brandon 关于动态类型语言中借用检查的实现实践（https://scattered-thoughts.net/writing/borrow-checking-without-type-checking）。