[Rust] Rust Const Generics 实战：密码学库重构，代码量减少85%并提升性能

从8347行缩减到1243行，一个密码学库的重构不仅大幅减少了代码量，更带来了显著的性能提升。这一切都源于Rust 1.51版本中稳定化的一个关键特性——Const Generics。

一个让我血压升高的下午

上周，一位前同事找我吃饭，聊起他最近接手维护的一个密码学库。他放下筷子，满脸疲惫地吐槽：“这代码写得，简直是灾难。”

原来，他们团队三年前为了一个人脸识别项目开发了一个库，其中需要处理多种固定尺寸的矩阵运算。当时的“解决方案”是：使用宏，生成了16套逻辑几乎完全相同的代码，分别对应尺寸16、32、64、128……就像俄罗斯套娃一样。

“你猜最后有多少行代码？”他伸出一根手指，“8347行。这还是在努力精简后的结果。”

我当时就想，这哪里是在写代码，分明是在“堆坟场”。“后来维护起来很痛苦吧？”我问道。

“何止是痛苦！”他苦笑道，“每次修复一个Bug，我都要在16个地方做一模一样的修改。一旦漏掉一个，第二天线上服务准挂。那半年，我的头发掉了差不多三分之一。”

看着他确实稀疏的头顶，我默默叹了口气。

直到 Rust 1.51 来了

“转机出现在2021年3月，”他喝了口汤，眼神突然亮了起来，“Rust 1.51正式稳定了Const Generics（常量泛型）。”

我有点懵：“常量什么？”

他擦了擦嘴，开始解释。这就像“量体裁衣”。以前的Rust泛型系统，好比裁缝只知道“这是一件衣服”，却无法区分它是S码还是XL码。

“听起来不是什么大问题？”我觉得他可能有些夸张。

“你听我说完，”他摆摆手，“这影响大了。在以前，你根本无法编写一个通用的函数来处理任意固定长度的数组。”

他拿起餐巾纸，画了个草图：

// 以前：想写一个通用函数？门都没有
fn process_16(data: [u8; 16]) { /* 处理 16 字节 */ }
fn process_32(data: [u8; 32]) { /* 处理 32 字节 */ }
fn process_64(data: [u8; 64]) { /* 处理 64 字节 */ }
// ... 一直写到 16 个函数

“看到了吗？”他说，“每个函数唯一的区别就是数组大小的数字，核心逻辑完全一样。但编译器认为 [u8; 16] 和 [u8; 32] 是完全不同的类型，所以你必须为每一种尺寸单独实现。”

我明白了，这就像去寄快递，快递站只认“箱子”这个类型，不关心箱子的大小。你说要寄个小号箱子，他却给你一本厚厚的型号目录让你选。

“那Const Generics是怎么解决这个问题的？”我产生了兴趣。

他笑了：“它让编译器明白，16、32、64……这些数字虽然不同，但它们代表的‘尺寸’概念可以作为类型的一部分进行参数化。”

// 现在：一个函数搞定所有尺寸
fn process<const N: usize>(data: [u8; N]) {
    // N 就是数组大小，在编译期就已确定
}

就这么简单？一个 <const N: usize>，16个重复函数合并成了1个。这正是 Rust 语言强大类型系统的体现。

“对，就这么简单，”他连连点头，“我当时看到这个语法，整个人都愣住了。我们团队折腾了整整三年，原来就在等这一颗‘语法糖’。”

85% 的代码是怎么没的

饭后我们换了家咖啡馆，他迫不及待地给我展示重构后的数据。“你猜重构完还剩多少行？”他把手机递过来，“1243行。”

我快速心算，从8347到1243，代码量确实减少了约85%。“但这还不是最惊人的，”他神秘兮兮地压低声音，“你猜性能变化如何？”

我摇摇头。他说：“在小数组运算上，平均性能提升了83%。整个项目的编译时间从23秒降到了9秒，生成的二进制文件体积也从847KB瘦身到了507KB。”

我差点把嘴里的咖啡喷出来：“等等，代码少了85%，性能反而快了一倍？你没开玩笑吧？”

他非常认真地摇头：“绝对没有。这里主要有两个原因。第一，Const Generics为编译器开启了前所未有的优化空间。比如，编译器知道确切的循环次数后，可以进行完全的循环展开、自动向量化（SIMD）以及更高效的数据预取。”

“第二呢？”

“第二，”他继续解释，“以前用宏生成的那些代码，内部存在大量重复和冗余的内存操作。使用Const Generics后，编译器能进行更深度的内联优化和常量折叠。许多原本在运行时进行的计算，直接在编译期就被完成了。” 这种编译期计算的能力，是理解 计算机基础 中编译器优化原理的绝佳案例。

他打开笔记本电脑，给我看了一段关键代码对比：

// 以前：16 套实现，每套都要动态分配内存
fn multiply_16(a: &[f32; 16], b: &[f32; 16]) -> Vec<f32> {
    let mut result = Vec::with_capacity(16); // 堆分配！
    // ... 计算
    result
}

// 现在：栈上直接算，零分配
fn multiply<const N: usize>(a: &[f32; N], b: &[f32; N]) -> [f32; N] {
    let mut result = [0.0; N]; // 栈上分配，编译期就知道大小
    // ... 同样的计算
    result
}

“看到了吗？”他指着屏幕说，“以前每次做矩阵乘法，都必须在堆上申请一块新内存。现在，结果数组可以直接在栈上创建，实现了零动态分配。内存分配在性能敏感的场景下是非常昂贵的操作，能避免则避免。”

生活中的 const generics

我让他举个更生活的例子。他想了想说：“你买过宜家那种需要自己组装的家具吧？”

“当然。”

“宜家柜子的每种型号，所需板材的种类和数量都是固定的。安装说明书会写：柜子A需要4块侧板、2块顶板、3块隔板……但如果你想设计一个通用的安装机器人，该怎么办？”

我表示不知道。他说：“Const Generics出现之前，你得为每种柜子型号单独写一套安装程序。A型号用程序A，B型号用程序B……16种型号就得写16套。”

“有了Const Generics之后，你只需要写一套通用程序：Cabinet<型号>{sides: 4, top: 2, shelves: 3}。然后告诉机器人‘这是16号柜’、‘那是32号柜’，机器人根据传入的‘型号’这个常量参数，自己就能知道需要处理哪些板材。”

我明白了：“所以，Const Generics就是把那些固定的‘配置参数’变成了类型系统的一部分？”

“没错，”他高兴地说，“这些‘型号’、‘尺寸’作为常量参数传入。编译器在编译时就知道这个‘柜子’有多大，需要多少‘板材’，无需在运行时再进行查表或计算。”

那些让人头疼的用法

“不过，”我提出疑问，“这个特性肯定也有它的限制吧？”

他点头：“当然有。首先，你不能在常量参数的位置进行任意复杂的运算。比如，你想写 impl<const N: usize> MyTrait for Matrix<N, N*N>，不好意思，目前还不支持在类型参数中直接进行乘法运算。”

其次，在常量上下文（const context）中不能进行堆内存分配。你无法写 const fn create_buffer() -> Vec<u8>，因为 Vec 的动态特性是运行时的。

“那遇到这种需求怎么办？”
“想办法绕过去，”他说，“比如提前计算好常量。如果你需要 N*N，可以先在外面定义好 const SIZE: usize = 4; const SQUARED: usize = SIZE * SIZE;，然后在类型中使用 Matrix<SIZE, SQUARED>。编译器足够聪明，它知道 SQUARED 的值。”

他还提醒，Const Generics可能会增加编译时间，因为每个不同的常量值都会生成一份独立的代码实例。但这通常是用编译时开销换取运行时性能，对于许多场景是值得的。

我们到底得到了什么

咖啡凉了，但我们越聊越投入。“我们来总结一下，”我帮他梳理，“Const Generics到底带来了哪些实实在在的好处？”

他掰着手指数起来：

1. 代码量锐减：彻底告别重复的代码拷贝，DRY（Don‘t Repeat Yourself）原则在数组和固定尺寸数据处理领域真正得以贯彻。
2. 性能显著提升：栈内存替代堆内存，编译期优化替代运行时计算，SIMD向量化替代串行循环。能从编译阶段解决的，绝不拖到运行时。
3. 更强的类型安全：编译器能在编译期就检查数组尺寸的匹配问题，将一大类潜在Bug扼杀在摇篮里，而不是等到线上崩溃。
4. 可维护性飞跃：Bug修复从“在多处重复修改”变为“在一处修改”。新同事阅读代码时，再也不会被一堆宏展开弄得晕头转向。

他停顿了一下，补充道：“最让我感慨的是，组里一个刚毕业的应届生，以前看到那些宏生成的代码就发怵。现在他看到Const Generics的写法，说‘这不就是普通的泛型嘛，我看得懂’。听到这句话，我差点没哭出来。”

所以什么时候该用

“那我应该在什么情况下考虑使用这个特性呢？”我最后问道。

他想了想：“当你同时满足这几个条件时：你处理的数组或矩阵大小是固定的、在编译期就能确定的；你对性能有较高要求，追求零拷贝、零分配；你已经开始出现大量重复代码模式，写宏感到痛苦，不写宏更痛苦。”

“反过来，如果你的数据大小取决于用户输入，只能在运行时确定，或者你的项目还处于快速原型阶段，代码结构频繁变动，那就先别用。Const Generics会拖慢编译速度，并且对运行时才能确定的大小无能为力。”

“归根结底，”他总结道，“它是一件强大的工具，而非银弹。用在合适的场景，它就是神器；用错了地方，反而会成为负担。”

我看了一眼窗外，天已经黑了。“临走前再问一句，”我看着他，“你那个密码学库，现在怎么样了？”

他站起身，伸了个懒腰：“活得很好。线上Bug数量减少了67%，新同事基本三个月就能上手核心模块。最关键的是，我们团队现在终于能按时一起吃午饭了，不用天天加班救火。”

他拍拍我的肩膀：“兄弟，听我一句，如果你现在的代码里还有很多 fn process_16、fn process_32 这样仅尺寸不同的函数，试试换成Const Generics。你一定会回来感谢我的。” 这种通过具体案例学习高效编程范式的经验，非常值得在 云栈社区 这样的技术平台与更多开发者分享和讨论。

小抄

一句话理解它：Const Generics 允许类型参数携带“尺寸”信息，实现了像量体裁衣一样的精确抽象。掌握它是深入Rust性能优化世界的关键一步。

这几种情况尽管用：

• 你要处理的数组/矩阵大小固定不变，且在编译期可知。
• 你对性能有极致追求，希望实现零动态分配和深度优化。
• 你发现自己开始频繁使用“复制-粘贴”或宏来生成相似代码时。

这几种情况先别用：

• 数据大小由用户输入决定，运行时才能知晓。
• 项目本身的编译速度已经非常缓慢，不宜再增加负担。
• 项目处于快速原型阶段，代码结构和需求尚不稳定。

踩过坑才懂的事：

• 常量参数中目前不支持复杂的表达式运算（如直接使用 N*N）。
• 常量函数（const fn）内部不能进行堆内存分配。
• 它会为每个不同的常量值生成一份独立的代码副本，本质上是“用编译时间换取运行时间”。