为何Rust的String未实现短字符串优化（SSO）？

一、为什么标准库 String 默认不实现 SSO？ #

Rust 的 String 直接基于 Vec<u8> 实现，未内置 SSO 主要源于以下设计考量：

• Vec 的设计约束：Vec 的核心布局是三个 usize 类型的字段（指针、长度、容量），64 位系统下占 24 字节。如果给 String 单独实现 SSO，要么修改 Vec 的结构（这会破坏所有依赖 Vec 布局的类型与代码，包括 unsafe 场景），要么让 String 脱离 Vec 实现——这会丢失 String 与 Vec<u8> 零成本转换的特性，违背标准库的简洁性原则。
• 移动语义与性能可预测性：SSO 会让 String 存在两种存储状态（栈内/堆上），所有字符串操作都需要增加分支判断来区分状态，这会降低性能的可预测性。虽然短字符串移动时栈内复制的成本与当前 String 移动（复制三个 usize）相当，但状态切换（短转长时从栈拷贝到堆）会带来额外开销，不符合 Rust 追求“零额外开销”的设计目标。
• 生态替代方案成熟：Rust 社区已有大量实现 SSO 的第三方字符串库（如 smallstr、smartstring），用户可根据业务场景（短字符串占比高）自行选择，标准库则保持通用、最小化的设计，避免给不需要 SSO 的场景带来隐性开销。
• 性能权衡：SSO 并非全场景优化，对于长字符串占主导的业务，分支判断会带来 5%-10% 的性能损耗；标准库优先保证大多数通用场景下的稳定、无分支性能。

二、未来能否给标准库 String 追加 SSO？ #

目前来看，标准库 String 内置 SSO 的可能性极低：

• 向后兼容性问题：修改 String 的内部结构会导致所有依赖其内存布局的代码（尤其是 unsafe 代码）失效，违背 Rust 对稳定性的承诺。
• 设计哲学冲突：String 作为 Vec<u8> 的直接包装，这种简洁的关系是标准库的核心设计之一，添加 SSO 会打破这种一致性，增加维护复杂度。
• 第三方方案已满足需求：社区现有的 SSO 字符串库已经覆盖了短字符串优化的场景，无需标准库重复实现。

三、SSO 的性能数据参考 #

SSO 在短字符串占比高的场景下收益显著：

• 减少堆分配次数，降低内存碎片，同时栈内数据的缓存命中率远高于堆上数据，在频繁创建、复制、销毁短字符串（如编译器令牌、枚举字符串、配置键值对）的场景中，使用 SSO 的字符串库比标准库 String 快 20%-50%。
• 但在长字符串为主的场景中，SSO 带来的分支判断会导致性能下降 5%-10%，因为每次操作都需要额外检查存储状态。

内容的提问来源于stack exchange，提问作者Jan Schultke