应避免用char*字面量直接初始化std::string变量；函数参数或容器初始化时需警惕隐式转换开销与生命周期问题；推荐花括号初始化；拼接优先用+=或append并预分配内存；substr前须检查索引有效性。
string 构造和初始化时，别直接用 char* 字面量赋值给 std::string 变量
很多人写 std::string s = "hello"; 看似没问题，但背后隐含一次从 C 风格字符串到 std::string 的构造——这没问题；真正容易出错的是在函数参数传递或容器初始化时忽略隐式转换开销或生命周期问题。
- 如果传入的
const char*指向栈上临时缓冲区（比如局部char buf[64]），又用它构造std::string并长期持有，后续访问会崩溃 - 在
std::vector<:string></:string>初始化时写{ "a", "b", "c" }是安全的，编译器会调用std::string(const char*)构造，但若混用std::string_view或自定义类型，可能触发意外重载解析 - C++11 起支持
std::string s{"hello"};（花括号初始化），更明确、禁用窄化，推荐用于避免隐式转换歧义
拼接字符串时，+ 和 += 行为差异大，尤其涉及右值
+= 总是就地修改，+ 总是新建对象。性能敏感路径下，频繁用 s = s + "x" 会产生大量临时 std::string 对象，而 s += "x" 复用内存。
-
s += "x"：内部通常检查容量，必要时 realloc，但只分配一次（如果预留足够） -
s = s + "x"：先构造临时std::string，再 move-assign 给s，至少一次额外分配（除非编译器 RVO 优化掉，但不保证） - 拼接多个片段时，优先用
std::string::append()或预先reserve()，比如：s.reserve(s.size() + len1 + len2); s += part1; s += part2;
用 substr() 提取子串前，必须检查索引是否越界
std::string::substr(pos, len) 在 pos > size() 时抛 std::out_of_range；len 超出剩余长度则自动截断——这个“自动”常被误认为安全，实则掩盖逻辑错误。
- 常见错误：对空字符串调用
s.substr(0, 1)→pos == 0 ？不，<code>0 == size()是合法的，但substr(0, 1)实际返回空串（因为 len 被截断为 0），结果看似“没崩”，却不符合预期 - 更稳妥写法：
if (pos - 如果只是想取后缀，用
s.substr(std::max(0, (int)s.size() - n))比硬算size()-n更防溢出（避免无符号回绕）
比较字符串大小写时，== 不区分大小写，得自己处理
std::string 的 ==、 等操作符完全基于字符 ASCII 值，没有内置大小写无关比较。别指望 <code>"Abc" == "abc" 返回 true。
立即学习“C++免费学习笔记（深入）”；
- 简单 ASCII 场景可用
std::equal(a.begin(), a.end(), b.begin(), b.end(), [](char x, char y) { return std::tolower(x) == std::tolower(y); }) - 注意
std::tolower要求unsigned char输入，直接传char可能在负值时 UB，应先转：static_cast<unsigned char>(x)</unsigned> - 国际化场景必须用 ICU 或
std::locale，但开销大；多数命令行工具/配置解析只需 ASCII 级忽略大小写，手写转换更轻量可控
C++ 的 std::string 接口简洁，但每个成员函数的边界条件、内存策略和隐式转换都藏在表层之下。最容易被忽略的是：它不是“零成本抽象”的字符串容器——构造、拷贝、拼接、查找都可能触发分配或遍历，而这些行为在调试器里看不见，只在压测时突然暴露。
