在编程语言编译器的实现中，借检查（Borrow Checking）是确保内存安全的关键机制。传统上，借检查与静态类型系统紧密绑定 ——Rust 编译器通过 MIR（Mid-level IR）上的数据流分析来追踪引用的生命周期与活跃度。然而，Jamie Brandon 在其语言实验项目中展示了一种无需静态类型系统的借检查实现方案：通过引用计数与活跃度追踪，在动态类型语言中实现内存安全。本文将深入探讨这一技术路径的工程实现细节，分析数据流图构建、活跃度分析以及动态借检查的具体参数与监控要点。
借检查的核心问题与数据流分析框架
借检查的核心目标是防止悬挂指针与数据竞争。具体而言，需要确保以下安全规则：其一，当一个值被借出（Borrow）时，其所有者（Owner）不能被移动或修改；其二，借出的引用不能超过被借值 的生命周期；其三，共享引用（Shared Borrow）与可变引用（Mutable Borrow）不能共存。在静态类型系统中，这些约束通过编译器在编译期进行验证；而在动态类型系统中，则需要在运行时通过追踪引用状态来实施检查。
数据流分析是解决这一问题的通用框架。其基本思想是将程序划分为基本块（Basic Block），在控制流图（Control Flow Graph）上迭代传播 facts，直到达到固定点（Fixed Point）。对于借检查而言，需要传播的 facts 包括：哪些变量当前被借出、哪些变量可能被共享、哪些变量的引用计数状态如何变化。Rust 编译器在 MIR 层上实现了这一框架，使用 rustc_mir_dataflow 模块提供的前向与后向数据流分析来计算这些信息。数据流框架的核心是定义域（Domain）和传递函数（Transfer Function）：域表示需要追踪的状态集合，传递函数描述每条语句如何修改该状态。
对于动态类型系统，由于缺乏编译期的类型信息，传统的静态分析无法直接应用。Jamie Brandon 的方案采用了运行时引用计数与借出状态追踪的混合策略。其核心数据结构为每个变量维护一个引用计数（RefCount），该计数可以处于四种状态：当计数等于 INT_MIN 时，表示该变量的值已被移动（Moved）；当计数小于零时，表示有若干借用（Borrow）指向该值；当计数等于零时，表示该变量可以被借出或共享；当计数大于零时，表示有若干共享引用（Share）指向该值。
活跃度分析与生命周期追踪
活跃度分析（Liveness Analysis）是借检查的另一关键组成部分。其目标是确定在程序的某个执行点，哪些变量可能在未来被使用。这一信息直接影响借检查的决策：当一个变量不再活跃时，其值可以被安全地释放或移动，无需担心破坏后续的借用。Rust 编译器在 MIR 层实现了两种活跃度分析：use-live（可用于后续使用）和 drop-live（可被_drop），后者对于非词法生命周期（Non-Lexical Lifetimes, NLL）的实现至关重要。
在动态类型系统中，活跃度分析与借检查紧密耦合。由于没有编译期的类型推导，运行时必须追踪每一份引用的来源（Provenance）、借出方式（Lease）以及所有者（Owner）。具体实现中，每一份借出或共享引用都维护三个关键信息：lease 表示引用的类型（owned、borrowed 或 shared）；lender 表示被借出的源变量，用于在引用_drop 时递减引用计数；owner 表示值的最终所有者，用于生命周期检查 —— 这在再借出（Reborrow）的操作中尤为重要，因为 lender 与 owner 可能不同。
考虑一个典型的再借出场景：let a = 1; let b = a&; let c = b!; 在此情况下，c 的 owner 记录为 a（而非 b），这是因为 c 最终借出的来源是 a，而 b 只是中间层。当执行 c* = 2 时，需要检查的不仅是 c 的 lender b 是否仍然有效，还要检查 c 的 owner a 的生命周期是否覆盖整个引用周期。这种设计确保了即使经过多层借出，生命周期约束仍能被正确追踪。
动态借检查的实现参数与监控要点
在实际工程实现中，动态借检查的性能开销主要来自引用计数的更新操作与借出状态的检查。以下是关键实现参数与监控建议：
引用计数存储策略：引用计数应始终存储在栈上，而非堆上，以降低缓存失效的开销。对于栈上变量，使用固定宽度的整数类型存储计数，例如在 Zig 实现中使用 std.math.IntFittingRange(-stack_size, stack_size) 来确保计数不会溢出栈大小。栈上的引用计数使得跨栈调用（Crossing Stacks）时的状态迁移更为可控。
借出检查的运行时复杂度：每次创建借出或共享引用时，只需进行单次整数比较即可判断是否允许操作。具体而言，可移动（CanMove）要求计数等于可用状态；可借出（CanBorrow）同样要求计数等于可用状态；可共享（CanShare）要求计数大于等于可用状态。这种设计将借检查的时间复杂度降至 O (1)。
错误报告与调试：动态借检查的一个优势在于能够提供精确的错误定位。当借出规则被违反时，系统不仅能识别违规的变量，还能扫描栈找到具体的借出位置。例如，当尝试对已借出的变量再次借出时，错误消息可以精确指出「不能借出 a，因为它已被 b[2][0] 借出」。这一功能通过扫描栈空间实现，复杂度为 O (stack_size)，但在错误处理路径上执行是可以接受的。
跨栈安全边界：当动态类型代码调用静态类型代码（或反之）时，需要进行状态迁移。实现中采用 with_new_stack 函数将闭包复制到新栈上执行，借出 / 共享引用的 provenance 会被重新映射到新栈上的虚拟 lender。这一机制确保了引用计数只在原栈与新栈的边界处更新，而非在每一次引用操作时都涉及跨栈操作。关键约束是：闭包的目标不能包含嵌套的借出 / 共享引用，且函数返回值不能包含借出 / 共享引用。
工程实践中的权衡与参数配置
在实际部署中，动态借检查的性能开销主要取决于借出操作的频率。对于高度函数式、很少使用引用的代码路径，引用计数开销几乎可以忽略；而对于需要频繁处理引用的数据结构（如树遍历、图算法），则需要关注以下配置参数：
借出计数阈值：设置合理的最大借出深度，防止过深的借出链导致性能退化与错误消息难以理解。建议将最大借出层级限制在 3 至 5 层，超出时报错并建议使用显式的所有权转移。
栈扫描预算：错误报告时的栈扫描操作应当设置超时或步数限制，避免在极端情况下（例如大量借出引用）导致程序卡死。建议将扫描步数限制在栈深度的两倍以内。
类型推断与混合策略：动态借检查可以与轻量级的类型推断结合，在运行时收集足够的类型信息后，将热点代码路径静态化。Jamie Brandon 指出，其系统中静态类型的代码路径无需承担引用计数开销，这一特性使得混合策略成为可能：动态类型提供灵活性，静态类型提供性能。
数据流分析与借检查的结合是编程语言编译器设计中的核心议题。静态类型系统通过编译期的数据流分析实现零运行时开销的借检查，而动态类型系统则通过运行时引用计数与活跃度追踪实现了类似的内存安全保证。两者的权衡实质上是灵活性与性能的权衡：静态系统在编译时完成所有检查，适合对性能要求严苛的场景；动态系统在运行时提供错误定位与灵活的类型切换，适合需要元编程与增量编译的场景。理解这些实现细节，有助于在实际系统设计中做出更合理的技术选型。
资料来源：Jamie Brandon, "Borrow-checking without type-checking", scattered-thoughts.net; Rust Compiler Development Guide, "MIR dataflow" 与 "The borrow checker".