SSO通过联合体+运行时长度判断决定存储方式：字符串长度≤缓冲区容量（如15/22字节）时存栈内缓冲区，否则分配堆内存并存储指针、size、capacity。
SSO 怎么判断该用栈还是堆
SSO 不靠魔法，靠的是 std::string 对象内部的联合体（union）+ 长度判断。它在构造或赋值时，检查字符串长度是否 ≤ 本地缓冲区容量（通常是 15 或 22 字符），满足就直接拷贝进对象内部的 char buf[16] 或 char buf[24]；超了就走传统路径：new char[n]，把指针、size、capacity 存进同一块内存里。
关键点是：这个判断发生在每次修改操作时（比如 operator=、assign()、append()），不是编译期决定的。所以一个 string 可能一开始走 SSO，后来扩容后就切到堆模式，再 shrink_to_fit 也不一定切回去——取决于实现。
- libstdc++（GCC）：缓冲区通常为 15 字符（+1
'\0'），sizeof(std::string) == 32 - libc++（Clang）：常见为 22 或 23 字符，
sizeof(std::string) == 24 - MSVC：多为 15 字符，
sizeof(std::string) == 16或24（取决于版本）
怎么验证当前 string 是否触发了 SSO
最直接的方法是看 data() 指针是否靠近 string 对象本身的地址——如果两者差值很小（比如
更稳妥的做法是用调试器观察内存布局，或写个小函数比对：
立即学习“C++免费学习笔记（深入）”；
std::string s = "hello"; std::cout << (s.data() == &s + 1) << '\n'; // 粗略判断：SSO 下 data() 常指向对象尾部附近
注意：&s + 1 是未定义行为，仅用于调试观察；正式代码别这么用。真正可靠的验证方式是结合 capacity() 和 data() 地址做区间判断，或者用 sanitizer 工具监控 malloc 调用。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
为什么改了字符串长度，sizeof(string) 却不变
sizeof(std::string) 是编译期常量，只由类定义决定，和它当前存的是 “a” 还是 “a million chars” 完全无关。SSO 的实现本质是复用同一块内存：用 union 让短字符串的缓冲区和长字符串的三元组（char*, size_t, size_t）共享空间。所以无论内容长短，对象体积固定为 24 或 32 字节。
这带来两个实际影响：
- 空字符串也占 32 字节（libstdc++），不是“零开销”——空间换时间
- 不能通过
sizeof推断字符串是否用了堆，必须看运行时行为 - 大量短字符串堆积时，栈上对象体积变大，可能影响 cache line 命中率
SSO 会干扰 move 语义或 swap 吗
不会干扰，但会影响 move 的“廉价程度”。SSO string 的 move 构造/赋值仍是 O(1)，但内部要根据当前模式分别处理：
- 源是 SSO 模式：直接 memcpy 内置缓冲区 + 复制
size - 源是堆模式：移交指针，把原对象置为空（
ptr=nullptr）
swap 也是安全的，标准库保证了两种模式下的位交换正确性。但要注意：如果手动写了基于 std::swap 的泛型逻辑，且没禁用 ADL，某些老版本 libstdc++ 曾因 union 成员未显式初始化导致未定义行为——2026 年主流版本已修复，但跨平台部署时仍建议用 std::string::swap() 成员函数而非全局 swap。
真正容易被忽略的是：SSO 让“小字符串 move”看起来和“大字符串 move”一样快，但如果你频繁构造临时 string（比如函数返回值），而这些 string 实际都 ≤15 字符，那它们根本没进堆——此时你优化堆分配的手段（如预留 capacity）完全无效，反而该关注栈拷贝和缓存局部性。
