每周性能技巧 #64：用更好的 API 设计延续摩尔定律
本节阅读量:本文翻译自 Abseil 官网的 Performance Tip of the Week #64: Continue Moore’s law with better API design。
原文发布于 2023 年 8 月 7 日，作者 Chris Kennelly，更新于 2025 年 7 月 16 日。
API 设计会决定未来能做哪些优化。好的 API 不仅表达当前需求，也保留实现自由度，使库可以在不修改调用方的情况下继续变快。本篇讨论如何通过 API 设计放大性能优化。
API 是优化边界
一旦 API 暴露了某些行为，用户就可能依赖它。即使文档没有承诺，Hyrum 定律也会让实现细节变成事实契约。之后再优化就更难。
如果 API 暴露了数据布局、迭代顺序、内存所有权或同步细节，库实现就失去许多选择。反过来，如果 API 只表达语义需求，实现可以在未来切换数据结构、批处理、缓存或延迟计算。
表达意图而不是实现
API 应该让调用方表达想做什么，而不是要求它说明怎么做。
例如，接受 absl::string_view 可以避免不必要字符串复制，同时不强迫调用方构造特定字符串类型。接受 range 或 span 可以让函数处理连续数据，而不暴露容器所有权。批量 API 可以让实现看到更多上下文，从而减少重复工作。
避免过早承诺
稳定性很重要，但不必要的承诺会锁死优化空间。常见危险包括：
- 承诺确定迭代顺序。
- 暴露内部指针稳定性。
- 允许用户依赖对象地址。
- 提供过多配置旋钮。
- 把缓存键、序列化格式或哈希算法作为永久契约。
如果某个属性未来可能阻碍优化，就应在 API 中避免承诺，或者通过随机化、测试和文档明确它不是契约。
用新 API 解锁新实现
有时，旧 API 无法高效表达需求。与其继续在旧接口下做复杂优化，不如设计新 API，让调用方提供更有用信息。
这可能需要迁移成本，但如果新 API 成为默认路径，后续优化可以惠及所有用户。API 设计是基础设施投资：一次迁移能带来多轮实现改进。
结语
随着硬件免费增长放缓，软件接口的设计越来越重要。保留实现自由度、表达语义而非机制、避免不必要承诺，可以让库在多年后仍然能继续变快。
