5. 字符串处理优化：std::string 的 COW 与 SSO、避免不必要的拷贝、使用 string_view

字符串处理，可以说是 C++ 项目里最频繁的操作之一。我见过不少性能问题，最后追根溯源，都卡在字符串上。你想想看，日志、配置、网络数据、用户输入……哪样离得开字符串？

今天我们就来聊聊字符串优化的三个核心点：COW 与 SSO 的内部机制、如何避免不必要的拷贝、以及string_view 的正确用法。这些东西搞明白了，你的程序能快不少。

5.1 std::string 的内存布局：COW 与 SSO

先说个历史故事。早期 C++ 标准库实现里，std::string 用的是 COW（Copy-On-Write，写时复制）策略。什么意思呢？就是多个 string 对象共享同一块内存，只有当某个对象要修改内容时，才真正拷贝一份。

听起来很聪明对吧？但实际用起来问题不少。我在项目中遇到过，多线程环境下 COW 的引用计数需要加锁，性能反而下降。而且 COW 导致指针、迭代器失效的语义变得很复杂。C++11 之后，标准明确禁止了 COW 实现。

SSO 的原理很简单：string 对象内部有一个固定大小的缓冲区（通常是 15 或 22 个字节，取决于实现）。当字符串长度小于这个阈值时，直接存在栈上的缓冲区里，不涉及堆分配。只有当字符串超过阈值，才去堆上分配内存。

我建议你记住这个阈值。比如在 libstdc++ 里，SSO 缓冲区是 15 字节（加上结尾的 '\0' 正好 16 字节对齐）。这意味着大部分短字符串（比如配置项、日志标签）根本不会触发堆分配。

实现	SSO 缓冲区大小	堆分配触发条件
libstdc++ (GCC)	15 字节	长度 > 15
libc++ (Clang)	22 字节	长度 > 22
MSVC STL	15 字节	长度 > 15

5.2 避免不必要的拷贝：从源头减少开销

字符串拷贝的开销，说白了就是两件事：内存分配和数据复制。堆分配本身就很慢（涉及系统调用），再加上 memcpy 大段数据，性能损耗肉眼可见。

我见过最典型的场景：函数参数传值。很多人写函数时习惯这么写：

// 不推荐：每次调用都会拷贝一次
void process_data(std::string s) {
    // 处理 s
}

// 推荐：传 const 引用，避免拷贝
void process_data(const std::string& s) {
    // 处理 s
}

嗯，这里要注意：如果你确实需要修改字符串的副本，那就传值。但如果你只是读取，传 const 引用就够了。别为了省事多写几个字，让程序白干活。

另一个常见坑是：在循环里反复构造 string。

// 糟糕的做法：每次循环都构造和析构
for (int i = 0; i < 100000; ++i) {
    std::string tmp = "prefix_" + std::to_string(i);
    // 使用 tmp
}

// 更好的做法：复用 string 对象
std::string tmp;
for (int i = 0; i < 100000; ++i) {
    tmp = "prefix_" + std::to_string(i);  // 复用缓冲区
    // 使用 tmp
}

为什么第二种更快？因为第一次赋值后，tmp 的缓冲区已经分配好了。后续赋值如果长度不超过已有容量，就不会重新分配堆内存。说白了就是「一次分配，多次使用」。

5.3 使用 std::string_view：零拷贝的字符串视图

string_view 是 C++17 引入的利器。它本质上是一个指向已有字符串的视图，包含一个指针和一个长度。它不拥有数据，所以构造和拷贝都极其轻量——就是复制两个指针/整数而已。

我建议你在以下场景优先使用 string_view：

• 函数参数：如果函数只读取字符串内容，不修改、不存储，用 string_view 替代 const string&
• 字符串分割/解析：返回子串时，用 string_view 避免拷贝
• 与 C 风格字符串交互：string_view 可以无缝对接 const char* 和 std::string

// 传统写法：每次分割都拷贝子串
std::vector<std::string> split(const std::string& s, char delim) {
    std::vector<std::string> result;
    std::stringstream ss(s);
    std::string token;
    while (std::getline(ss, token, delim)) {
        result.push_back(token);  // 拷贝
    }
    return result;
}

// 优化写法：使用 string_view，零拷贝
std::vector<std::string_view> split(std::string_view s, char delim) {
    std::vector<std::string_view> result;
    size_t start = 0;
    size_t end = s.find(delim);
    while (end != std::string_view::npos) {
        result.push_back(s.substr(start, end - start));  // 视图，不拷贝
        start = end + 1;
        end = s.find(delim, start);
    }
    result.push_back(s.substr(start));
    return result;
}

你看，第二种写法里，substr 返回的是 string_view，它只是记录了起始位置和长度，没有复制任何字符数据。这在处理大文本时效果非常明显。

举个例子：

std::string_view get_view() {
    std::string s = "hello";
    return s;  // 危险！s 在函数结束时被销毁
    // 返回的 string_view 指向已释放的内存
}

// 正确做法：确保原始数据存活
std::string_view get_view(const std::string& s) {
    return s;  // 安全，s 的生命周期由调用者管理
}

我个人习惯是：在函数参数里用 string_view，在返回值里尽量用 std::string（除非你能保证原始数据长期存活）。

5.4 知识体系总览

下面这张图总结了字符串优化的核心逻辑，你可以对照着梳理自己的代码：

5.5 实战建议

说了这么多，我总结几条可以直接用的建议：

1. 默认用 std::string，别自己造轮子。SSO 已经帮你处理了短字符串的优化。
2. 函数参数优先用 const std::string& 或 std::string_view。如果函数内部需要存储字符串，再考虑传值。
3. 在循环外声明 string 对象，利用缓冲区复用减少堆分配。
4. 字符串分割、查找子串等操作，优先用 string_view，避免不必要的拷贝。
5. 永远注意 string_view 的生命周期。它不拥有数据，原始数据销毁后就不能用了。

字符串优化其实不难，核心就是「少分配、少拷贝」。你写代码时多问自己一句：「这个字符串真的需要拷贝吗？」——答案往往是不需要。