字符串处理与优化：std::string 底层实现、SSO 优化、字符串拼接性能对比、自定义字符串类
字符串处理，几乎是每个 C++ 项目里最频繁的操作之一。我见过不少线上服务，性能瓶颈就卡在字符串拼接和拷贝上。说实话，很多人用 std::string 用了好几年，却不知道它底层是怎么运作的。今天我们就把它彻底讲透。
std::string 的底层实现
std::string 并不是一个简单的「字符数组」。它内部维护了三个关键指针：
- start：指向字符串起始位置
- finish：指向当前字符串末尾（即 '\0' 之前）
- end_of_storage：指向已分配内存的末尾
说白了，它就是一个动态管理的字符缓冲区。当你执行 str = "hello" 时，底层会做三件事：检查容量是否足够、拷贝数据、更新 finish 指针。
核心要点：std::string 的拷贝构造函数和赋值运算符，在 C++11 之后默认走「移动语义」，而不是深拷贝。这是性能提升的关键之一。
SSO 优化：小字符串的福音
你想想看，如果每个字符串都去堆上分配内存，那对于 "hi"、"yes"、"no" 这种短字符串来说，开销太大了。SSO（Small String Optimization）就是解决这个问题的。
SSO 的原理很简单：在 std::string 对象内部预留一块栈上空间（通常是 15 或 22 字节，取决于实现）。当字符串长度小于这个阈值时，直接存在栈上，不触发堆分配。
我在项目中遇到过一个问题：一个高频调用的日志函数，每次传入的 tag 字符串长度不超过 10 个字符。一开始没注意，后来用 perf 分析发现，大量时间花在 malloc/free 上。启用 SSO 后，性能提升了将近 30%。
个人建议：如果你的字符串绝大多数都小于 15 字节，直接用 std::string 就好，SSO 会帮你省掉堆分配的开销。别自己造轮子。
字符串拼接性能对比
字符串拼接，看起来简单，但不同方式的性能差距可以到几十倍。我整理了一张对比表：
| 拼接方式 | 时间复杂度 | 内存行为 | 推荐场景 |
|---|---|---|---|
str = str + "a" |
O(n²) | 每次创建临时对象 | 绝不推荐 |
str += "a" |
O(n) 均摊 | 可能触发重新分配 | 少量拼接 |
str.append("a") |
O(n) 均摊 | 同 += | 链式调用 |
std::ostringstream |
O(n) | 内部缓冲区管理 | 格式化拼接 |
fmt::format |
O(n) | 预分配 | 现代 C++ 推荐 |
reserve + += |
O(n) | 零重新分配 | 高性能场景 |
看到没？str = str + "a" 是 O(n²) 的。为什么？因为每次拼接都会创建一个新的临时 string 对象，然后销毁旧的。循环里这么写，基本就是在烧 CPU。
我曾经接手过一个消息网关项目，里面有一段代码用 + 拼接了上千次字符串。压测时 QPS 死活上不去。改成 reserve + += 之后，QPS 直接翻了一倍。
避坑指南：我曾经在循环里用 str = str + std::to_string(i)，结果内存碎片化严重，服务跑了半小时就 OOM 了。后来改成 str += std::to_string(i)，问题解决。记住：循环拼接一定要用 += 或 append。
自定义字符串类：什么时候需要？
std::string 已经很强大了，但有些场景下，你确实需要自己动手。我总结了几种情况：
- 固定长度字符串：比如 IP 地址、UUID，长度已知且固定，用 std::string 浪费了动态分配的开销
- 零拷贝需求：某些场景下你只想引用一段内存，不想拥有它。std::string_view 可以部分解决，但如果你需要更多控制，就得自己写
- 特殊内存分配器：比如你需要从共享内存或内存池中分配字符串，std::string 的默认分配器不适用
下面是一个简单的固定长度字符串类示例：
class FixedString {
char data_[64]; // 固定 64 字节
size_t len_ = 0;
public:
FixedString(const char* s) {
len_ = std::min(strlen(s), sizeof(data_) - 1);
memcpy(data_, s, len_);
data_[len_] = '\0';
}
const char* c_str() const { return data_; }
size_t size() const { return len_; }
};这个类没有堆分配，没有析构开销。对于短字符串场景，性能非常稳定。
我的经验：自定义字符串类一定要考虑「空状态」和「边界情况」。我曾经写过一个类，忘了处理空字符串，结果在边界条件下 memcpy 了 0 字节，虽然没崩溃，但行为不符合预期。嗯，单元测试真的很重要。
知识体系结构图
下面这张图总结了本章的核心逻辑：
总结
字符串处理看似基础，但里面的门道不少。我个人习惯是：
- 默认用 std::string，享受 SSO 带来的红利
- 循环拼接前先 reserve 足够的容量
- 遇到性能瓶颈时，先检查字符串操作是不是热点
- 只有在极端场景下才考虑自定义字符串类
记住一句话：不要过早优化，但也不要忽视基础操作的性能成本。字符串处理就是那种「看起来简单，但优化空间巨大」的地方。