SSO（短字符串优化）省去的是堆内存分配——短字符串直接存于std::string对象内部缓冲区，避免调用new。如libstdc++用15字节（含'\0'）存短串，size()即指示其长度。
std::string 的 SSO 是什么，它到底省了哪块内存
SSO（Short String Optimization）不是标准强制要求，而是主流实现（如 libstdc++、libc++、MSVC STL）普遍采用的优化策略：当字符串长度很短时，不堆分配内存，而是把字符直接存进 std::string 对象内部的固定缓冲区里。
关键点在于「避免堆分配」——哪怕只存 1 个字符，普通实现也要调 new；SSO 实现则用对象自身的字节（比如 23 字节）直接存内容，size() 和 c_str() 都从这块内联缓冲区读。
- 典型容量：libstdc++（GCC）是 15 字节（含结尾
\0），libc++（Clang）是 22 字节，MSVC 是 15 字节（x64） - 判断依据是
size() ，不是长度为 0 或 1 就触发 - 一旦超过阈值（例如第 16 个字符），立刻退化为堆分配，此时内部指针指向
new出来的内存
怎么知道我的 std::string 当前走的是 SSO 还是堆分配
没有标准接口能直接查，但可通过地址对比间接验证：SSO 下 c_str() 返回的地址应落在 std::string 对象内存范围内；堆分配时则明显不同。
实操建议用调试器或打印地址比对：
立即学习“C++免费学习笔记（深入）”；
std::string s1 = "hello"; // 短，大概率 SSO
std::string s2 = std::string(30, 'x'); // 长，必然堆分配
printf("s1.data(): %p, &s1: %p\n", (void*)s1.data(), (void*)&s1);
printf("s2.data(): %p, &s2: %p\n", (void*)s2.data(), (void*)&s2);
- 若
s1.data()地址在&s1到&s1 + sizeof(std::string)范围内，基本可断定 SSO 生效 - 不要依赖
sizeof(std::string)值判断——它恒定（如 24 或 32 字节），和是否 SSO 无关 - 不同编译器/标准库的 SSO 阈值不同，别硬编码 15 或 22 做逻辑分支
SSO 会影响 move、copy 和比较行为吗
会影响，而且影响方式不统一——这是最容易踩坑的地方。
-
move：SSO 字符串 move 后，原对象通常仍保持有效（内容未清空，size()不变），但标准只要求 move 后“可析构、可赋值”，不保证内容。别假设 move 后源变空 -
copy：SSO 字符串 copy 是深拷贝（复制缓冲区内容），不是共享；堆分配字符串 copy 才可能触发 COW（但现代实现基本已弃用 COW） -
operator==：无论 SSO 还是堆分配，比较都是逐字符，性能差异仅在于缓存局部性——SSO 数据在栈上，访问更快 - 注意
data()返回的指针生命周期：SSO 下它随对象生命周期结束而失效，不能长期保存
什么时候该关心 SSO，什么时候可以忽略
绝大多数业务代码完全不用管 SSO —— 它是底层透明优化。真正需要留意的场景很窄：
- 做高性能字符串拼接（如日志组装），反复构造小字符串时，SSO 能显著减少
malloc/free开销 - 调试内存泄漏或 heap profiler 报告异常时，发现大量小块堆分配消失，可能是 SSO 在起作用，别误判为 bug
- 跨 DLL 边界传递
std::string（尤其 Windows MSVC），若两边 STL 版本或编译选项不同（如 _ITERATOR_DEBUG_LEVEL），SSO 缓冲区布局可能不兼容，导致越界读——这时宁可显式用std::string_view或 C 风格接口
SSO 的边界模糊、实现依赖强，且不改变语义。比起猜它是否生效，更稳妥的做法是：用 reserve() 控制预期容量，用 shrink_to_fit() 主动释放堆内存，而不是靠 SSO 阈值做逻辑分支。
