std::string构造可能意外拷贝因隐式转换或临时对象；find返回npos需判空防越界；clear不释放内存，shrink_to_fit非强制，交换法可强制释放。
string 构造和初始化为什么有时会意外拷贝？
直接用 std::string 构造时，看似简单的写法可能触发隐式转换或临时对象拷贝，尤其在传参或返回值场景下。比如 func(std::string("hello")) 会构造一个临时对象再移动（C++11+），但若函数参数是 const char*，编译器可能不走你预期的路径。
- 避免隐式转换：显式构造，如
std::string s = "hello"比std::string s("hello")更易读，且 C++17 后 guaranteed copy elision 让前者更安全 - 慎用
std::string(const char*)构造：若传入空指针，行为未定义；务必确保 C 字符串以'\0'结尾 - 移动语义不是万能的：返回局部
std::string通常自动移动，但若函数声明为std::string&&返回，反而可能抑制优化，还增加调用方理解成本
find 和 substr 配合使用时下标越界怎么防？
std::string::find 找不到时返回 std::string::npos（本质是 size_t 最大值），直接拿它当索引传给 substr 会出大事——因为 size_t 是无符号类型，npos + 1 会回绕成 0，导致 substr(0, ...) 意外截取整串。
- 必须先判断：
if (pos != std::string::npos) { s.substr(pos, len); } -
substr第二个参数是长度，不是结束位置；超长时自动截断到末尾，不会报错但结果可能不符合预期 - 用
std::string_view替代频繁substr可避免内存分配，但要注意其生命周期不能超过原string
append、operator+= 和 += 字符串字面量有啥区别？
三者语义接近，但底层行为和兼容性有微妙差异。尤其在处理窄字符串字面量（如 "abc"）时，operator+= 和 append 的重载解析可能不同。
-
s += "abc"调用的是operator+=(const char*)，效率高，直接追加字节 -
s.append("abc")默认调用append(const char*, size_t)，需计算长度；但append("abc", 3)显式指定长度更可控 - 混用宽窄字符容易编译失败：比如
s += L"abc"会报错，因为std::string不支持宽字符字面量 - 性能上，
+=通常略快于append，但差别微乎其微；优先选可读性高的写法
clear() 不释放内存，那怎么真正 shrink_to_fit？
std::string::clear() 只清内容、长度归零，但容量（capacity）不变。反复 clear + assign 可能导致内存持续占用，尤其在长期运行的服务中。
立即学习“C++免费学习笔记（深入）”；
-
s.clear(); s.shrink_to_fit();是标准做法，但注意：C++11 起shrink_to_fit是非强制请求，实现可忽略（libc++ 通常响应，MSVC 也基本响应） - 想彻底控制内存，可用交换惯用法：
std::string().swap(s)，强制释放所有内存（包括小字符串优化 SSO 占用的空间） - SSO 字符串（短字符串优化）下，
shrink_to_fit对小串无效——因为内存根本没堆分配，谈不上“收缩”
npos 当普通整数用，以及默认认为 clear() 就等于“释放内存”。 
