std::string 不能直接用 == 比较 c 风格字符串，因为 == 对 std::string 重载为内容比较，而对 const char* 是指针比较；"hello" == std::string("hello") 编译失败，str.c_str() == "hello" 总是 false（地址不同）；应统一转 string 或用 std::strcmp。
std::string 为什么不能直接用 == 比较 C 风格字符串？
因为 == 对 std::string 是重载过的，能安全比较内容；但对 const char* 是指针比较，只看地址是否相同。一不留神就逻辑错得离谱。
- 常见错误现象：
"hello" == std::string("hello")编译失败；str.c_str() == "hello"总是 false（除非巧合指向同一字面量） - 正确做法：统一转成
std::string再比，或用std::strcmp（需包含<cstring></cstring>） - 示例：
if (str == std::string("hello"))或if (std::strcmp(str.c_str(), "hello") == 0) - 性能影响：临时构造
std::string有少量开销，高频场景优先用std::strcmp
substr() 越界时为啥不报错反而返回奇怪结果？
substr() 的设计是“宽容”的：当起始位置超出长度，直接返回空串；当要取的长度超了，就只取到末尾。这不是 bug，是标准行为，但容易掩盖逻辑错误。
- 常见错误现象：写
s.substr(10, 5)时s只有 3 个字符，结果得到空串，后续操作崩溃或静默出错 - 安全写法：先检查
pos ，再调用 <code>substr() - 注意参数顺序：
substr(pos, len)，不是(start, end)；len默认是std::string::npos（即到末尾） - 兼容性：所有 C++11 及以上版本行为一致，别依赖“越界报异常”
用 + 拼接 string 和字面量时，内存分配怎么悄悄变慢？
每次 + 都可能触发一次堆分配——尤其循环里反复拼接，会形成 O(n²) 的拷贝开销。编译器未必能优化掉。
- 使用场景：日志拼接、路径组装、模板填充等高频字符串构建
- 更高效的做法：用
std::ostringstream，或 C++20 的std::format（如果可用），或预估长度后用reserve()+append() - 示例：
s.reserve(256); s.append("user: ").append(name).append("@").append(domain); - 坑点：
"a" + str + "b"中，"a"是const char*，第一个+就得构造临时std::string，后面才进入重载链
clear() 之后 capacity() 还在，怎么真正释放内存？
clear() 只清内容，不缩容；capacity() 保持不变。想彻底释放内存，得绕一下。
立即学习“C++免费学习笔记（深入）”；
- 常见误解：以为
clear()后内存就还给系统了 - 真正释放方法：用
std::string().swap(s)，或 C++11 起的s.shrink_to_fit()（但它是非强制的，实现可忽略） - 性能权衡：
shrink_to_fit()可能引发一次复制，仅在确认后续长期不用且内存敏感时才值得做 - 注意：
swap()方式会破坏迭代器和引用有效性，shrink_to_fit()不保证立即生效
capacity、c_str() 生命周期、隐式构造这些点，一松懈就埋进 runtime 错误里。尤其是跨函数传 c_str() 或混用 char* 和 std::string 的地方，得盯紧所有权和生存期。 
