在大型 Go 项目中，代码生成是一种常见的性能优化手段：将计算结果固化在源码里，省去运行时的重复计算。然而，当生成代码的规模突破某个阈值后，收益会迅速递减，甚至转为负向。Tim Bray 在其模式匹配库 Quamina 中添加 Unicode 属性正则支持时，就遇到了这个问题。他的解决方案不是优化生成流程，而是彻底放弃预生成，转向运行时缓存。这个决策背后的工程权衡值得深入剖析。
背景：Unicode 属性正则的工程需求
Quamina 是一个高性能模式匹配库，支持用类似正则的语法匹配 JSON 事件。Unicode 属性匹配是用户长期期待的功能，允许使用 \p{L} 匹配任意字母、\p{Zs} 匹配空格字符、\p{Nd} 匹配十进制数字等。这类表达式在国际化场景下非常实用，但实现起来需要依赖 Unicode 字符数据库。
Go 标准库的 unicode 包确实提供了字符分类功能，但有一个关键限制：它不会随 Unicode 版本同步更新。截至 2026 年 1 月，Go 的 Unicode 支持仍停留在 15.0.0 版本（2023 年 9 月发布），而最新的 Unicode 标准已经是 17.0.0。对于 Quamina 这样面向全球用户的库来说，接受这个版本差意味着部分新字符将无法正确识别。因此，Bray 选择了直接解析 Unicode 官方数据文件 UnicodeData.txt，确保与最新标准保持同步。
从 UnicodeData.txt 中提取属性信息并非难事：这个文件使用分号分隔字段，只需提取第一列（码点）和第三列（分类）即可。真正的挑战在于后续的自动化处理。最终得到的 37 个 Unicode 分类共包含 14,811 个码点对，总生成代码行数为 5,122 行。这只是开始。
第一次尝试：预生成代码的规模爆炸
在最初的设计中，Bray 打算将所有 Unicode 属性匹配的自动机（automaton）预先计算好并序列化到 Go 源码中。这样做的好处是运行时无需任何计算，纯内存查找即可完成匹配。然而，当他完成一半类别的处理时，生成代码已经达到 775,000 行，文件体积约 12MB。
这个规模带来了几个实际问题。首先是编译时间。Go 编译器在处理如此大的单一源文件时会出现明显的停顿，虽然最终能够编译通过，但开发迭代的节奏被打破。其次是 IDE 稳定性。Bray 使用 GoLand 开发，频繁打开这个巨大的源文件会导致 IDE 崩溃或严重卡顿。最关键的是，他意识到这还只是完成了一半的工作量 —— 补全 complement 版本（即 \P{L} 这种反向匹配）后，代码量将突破 150 万行。
在 77.5 万行时喊停是一个明智的决策。继续优化生成算法或压缩数据结构固然可能减少一些代码行数，但无法解决根本问题：静态代码生成的边际收益已经为负。
转折点：运行时缓存的逆向方案
Bray 随后采用了完全相反的策略：不在构建时生成任何代码，而是在运行时按需计算自动机，然后缓存结果供后续使用。这个方案的核心思想是「一次计算，多次复用」。对于一个长期运行的 Quamina 实例而言，每个 Unicode 属性只需要被计算一次，后续的匹配请求将直接使用缓存的自动机。
实现这个策略后，性能数据发生了戏剧性变化。最初的无缓存实现只能以每秒 135 次的速度向 Quamina 实例添加 Unicode 属性模式；而启用缓存后，这个数字飙升至每秒 4,330 次，提升幅度达到 30 倍。这个结果看似与「放弃代码生成」的直觉相悖，但背后有其合理的解释。
预生成方案的问题在于，它将所有可能的自动机一次性加载到内存中，无论这些自动机是否会被用到。对于实际运行场景而言，用户可能只使用一小部分 Unicode 属性，大量预生成的代码成了沉默的负担。运行时缓存则精确得多：只计算实际用到的属性，且只计算一次。对于长期运行的服务器进程而言，这个开销可以忽略不计；对于短生命周期的工具进程，则可以通过共享缓存或延迟初始化进一步优化。
工程决策的深层考量
这个案例揭示了一个经常被忽视的软件工程原则：静态与动态的权衡不能仅凭「静态更快」的直觉来决定。当预计算的成本低于运行时计算时，静态生成是有价值的；但当预计算的规模带来维护性、编译性、内存占用等副作用时，动态方案可能更优。
具体到 Quamina 的场景，有几个关键因素促成了缓存方案的胜出。第一是数据的稀疏性：37 个 Unicode 分类中，大多数在实际应用中极少使用，L（字母）分类包含 1,945 个码点对，而 Zl 和 Zp（行分隔符和段落分隔符）各只有 1 个。预生成意味着为这些长尾用例支付固定成本，而缓存策略允许按需付费。第二是运行时环境的特点：Quamina 通常作为长时间运行的服务存在，一次性计算的开销可以分摊到整个服务生命周期。第三是开发体验的隐性成本：IDE 稳定性、编译速度、代码审查便利性等都会受到超大规模源文件的影响，这些成本往往被低估。
值得注意的是，Bray 在文章中也提到了 GenAI。他反思自己本可以让 Claude 辅助完成那些「极其 routine」的编码任务 —— 解析 UnicodeData 文件、生成码点对列表、编写单元测试等 —— 但因为工具配置和急于动手的心态，他没有使用。这个细节说明，即使是经验丰富的工程师，在面对机械性编码工作时也可能做出非最优的决策。GenAI 在这类场景下的潜力值得关注，但前提是要建立好工作流。
何时选择运行时缓存而非代码生成
Quamina 的案例提供了一套可迁移的决策框架。当考虑是否使用代码生成时，工程师应该评估以下几个维度。
首先是预期使用率。如果生成代码中只有小部分会被实际调用，缓存方案更优；如果大部分生成代码都会被用到，预生成可能更合理。以 Quamina 为例，实际应用中极少出现对冷门 Unicode 分类（如 Zl、Zp）的匹配需求，缓存的精确性优势明显。其次是数据变化的频率。如果底层数据经常更新，缓存失效后的维护成本会很高；如果数据稳定，一次计算长期受益，预生成更省事。Unicode 标准的更新周期约为半年，Quamina 通过解析最新数据文件来跟进，这个过程本身是动态的，天然适合运行时处理。最后是编译与加载开销。对于需要快速启动的 CLI 工具，预生成的启动时零计算优势可能更有价值；对于后台服务，这个优势则不那么关键。
在 Go 语言生态中，代码生成的使用非常普遍，从 go generate 到各种 protobuf、gRPC 代码生成器，再到数据库访问层的自动生成。开发者往往倾向于「能省则省」的思路，却很少停下来计算预生成的隐性成本。Quamina 的案例提醒我们：规模达到一定程度后，动态方案不仅可接受，甚至可能更优。
结论：规模改变答案
同一个工程问题，在不同规模下可能有截然相反的最优解。77,500 行和 775,000 行之间的鸿沟，不仅是数量的变化，更是质的变化 —— 开发工具开始崩溃、编译时间变得无法忽视、维护成本急剧攀升。及时识别这个临界点并调整策略，是经验丰富的工程师与新手的重要区别。
Bray 最终没有生成那 150 万行代码。相反，他在运行时缓存的基础上实现了 Unicode 属性匹配，性能提升 30 倍，IDE 不再崩溃，开发体验回归正常。这个选择看似是「技术的倒退」，实则是工程判断力的体现：不是所有性能问题都需要通过预计算解决，有时候，让计算在合适的时机发生，反而更优雅、更可持续。
资料来源：本文核心内容源自 Tim Bray 的博客文章《Losing 1½ Million Lines of Go》，以及 Quamina 开源项目仓库。