std::string构造和初始化崩溃主因是空指针或野指针解引用导致段错误；substr与find组合易因npos未检查引发越界；compare与strcmp混用、data()空串风险、reserve与resize语义混淆亦为常见隐患。
string 构造和初始化为什么有时会崩溃
直接用 char* 初始化 std::string 时，如果指针为空或指向已释放内存，构造函数会解引用空指针或野指针——不是抛异常，而是未定义行为，常见表现是段错误。C++11 起 std::string 不再接受空 const char*，但部分旧编译器（如 GCC 4.8 前）可能静默通过，运行时报错。
- 安全做法：初始化前检查指针有效性，或改用
std::string_view（C++17）做只读视图，它允许空指针构造但不访问内容 - 避免写
std::string s(p);，改用std::string s(p ? p : ""); -
std::string的c_str()返回值生命周期绑定到字符串对象本身，别保存它的返回指针长期使用
substr 和 find 容易越界的两个典型场景
substr(pos, len) 和 find() 组合使用时，常因忽略返回值为 std::string::npos 或越界索引导致崩溃或逻辑错误。比如 s.substr(s.find("key") + 4)，若没找到 "key"，find 返回 std::string::npos（通常是 18446744073709551615），加 4 后仍是极大值，传给 substr 就触发 std::out_of_range。
- 永远先判断
find结果：auto pos = s.find("key"); if (pos != std::string::npos) { ... } -
substr的pos参数超过size()会直接抛异常；len超过剩余长度则自动截断，这点反而安全 - 用
std::string_view替代频繁substr可避免内存拷贝，尤其在解析循环中
compare、== 和 strcmp 混用引发的隐式转换问题
把 std::string 和 C 风格字符串混在比较表达式里，比如 s == "abc" 是安全的（有重载），但 strcmp(s.c_str(), "abc") 在 s 为空时没问题，而 strcmp(s.data(), "abc") 在 C++11 前不保证末尾有 <p>把 <code>std::string 和 C 风格字符串混在比较表达式里，比如 s == "abc" 是安全的（有重载），但 strcmp(s.c_str(), "abc") 在 s 为空时没问题，而 strcmp(s.data(), "abc") 在 C++11 前不保证末尾有 \0，可能读越界；更隐蔽的是 s.compare("abc") > 0 和 s > "abc" 行为一致，但前者返回整数，后者返回 bool，类型混淆容易在条件分支中埋雷。
s.compare("abc") > 0 和 s > "abc" 行为一致，但前者返回整数，后者返回 bool，类型混淆容易在条件分支中埋雷。
- 优先用
==/!=做相等判断，语义清晰且支持string和字面量直接比较 - 需要三态比较（小于/等于/大于）时用
compare()，别自己封装strcmp -
s.data()在 C++11 后保证以\0结尾，但仅当s.size() > 0时才可安全用于strlen类函数；空字符串时data()可能返回任意地址，别拿来传给 C 函数
reserve、resize 和 capacity 的性能差异在哪
想提升字符串拼接性能时，很多人只记得 reserve()，却忽略 resize() 的副作用：它会实际填充字符（默认 \0），而 reserve() 只预分配内存不改变 size()。误用 resize() 会导致后续 += 或 append() 在已有填充位置上覆盖，或者意外引入大量空字符。
立即学习“C++免费学习笔记（深入）”；
- 批量追加前用
s.reserve(expected_total_size)，避免多次 realloc -
s.resize(n)仅当你明确需要长度为n的字符串（含填充）时才用，比如构造缓冲区 -
capacity()返回当前分配容量，size()返回有效字符数；二者差值就是还能追加多少字符不 realloc - 用
s.clear()不会释放内存，shrink_to_fit()才尝试释放冗余容量（非强制）
c_str() 和 data() 的有效范围、npos 的数值本质、以及 reserve 和 resize 的语义差别——这些地方写错，编译器不报错，但运行时行为就不可控了。 
