C风格字符数组易出错因无自动生命周期管理，越界、缺\0、strcpy不检查长度、返回局部数组地址均导致崩溃；std::string在C接口、嵌入式、小对象等场景反而更麻烦。
C风格字符数组的内存管理为什么总出错
因为 char[] 没有自动生命周期管理，越界读写、忘记 \0、strcpy 直接崩掉都是常态。你不是写错了逻辑，是踩进了C语言没帮你兜底的坑里。
-
char buf[10]存不下 10 个字符——第 11 位必须留给\0，否则strlen或printf("%s", buf)会一路扫到内存垃圾 -
strcpy(dest, src)不检查dest大小，src超长就直接覆盖栈上其他变量（常见段错误或静默数据污染） - 函数返回局部
char[]地址？那地址一出作用域就失效，拿到的是野指针，用printf可能碰巧打印对，但换个编译器或优化等级就崩
std::string 在哪些场景下反而更麻烦
它不是银弹，尤其在和C接口打交道、嵌入式受限环境、或追求极致小对象拷贝时，std::string 的堆分配、异常抛出、ABI不稳定性会立刻冒头。
- 调用系统API（如
open()、connect()）或C库函数（如sqlite3_exec()）时，必须用s.c_str()，且要确保s的生命周期长于C函数调用——临时std::string("abc").c_str()是悬垂指针 - 频繁构造短字符串（比如循环里
std::string s = "x" + std::to_string(i)），可能触发多次小内存分配；而char buf[32]栈上搞定，零分配 - 跨DLL/so边界的
std::string传递风险高：不同编译器或标准库版本的内部布局可能不兼容，std::string成了ABI雷区
混合使用时怎么避免 const char* 和 std::string 转换翻车
转换本身安全，但“什么时候转”“谁负责释放”“是否需要持久化”才是关键。多数崩溃不是转错了，是转完忘了上下文约束。
- 接收C函数输出的
const char*（如getenv("PATH")），别直接塞给std::string构造函数就完事——如果该指针指向静态缓冲区（如strerror_r的旧版实现），后续调用可能复用同一块内存，导致std::string内容突变 - 想把
std::string传给要求char*（非 const）的C函数？不能强转(char*)s.c_str()——c_str()返回 const，强转后修改会触发未定义行为；正确做法是复制到可写缓冲区：std::vector<char> buf(s.begin(), s.end()); buf.push_back('\0');</char> -
std::string_view是更轻量的中间态，但注意它不拥有数据——若源std::string被析构或重分配，string_view立刻失效
性能敏感代码里，std::string 的隐式拷贝藏在哪
看起来没写 = 或 copy，但参数传递、返回值、甚至某些成员函数调用都在悄悄拷贝。尤其在 C++11 以前或禁用 RVO/NRVO 时更明显。
立即学习“C++免费学习笔记（深入）”；
- 函数参数写
void f(std::string s)→ 值传递，每次调用都深拷贝；改成const std::string& s或std::string_view s（C++17+） - 返回局部
std::string（如return std::string("ok");）通常靠返回值优化（RVO）避免拷贝，但若函数有多个 return 分支、或编译器优化关闭，就真拷贝；可显式用std::move(s)提示移动语义 -
s += "suffix"一般不会重新分配（只要容量够），但s = s + "suffix"必然新建对象再赋值，触发两次分配+拷贝
最易被忽略的点：调试构建下 std::string 的 debug mode（如 libstdc++ 的 _GLIBCXX_DEBUG）会额外检查边界，性能差一个数量级——别拿 Debug 版本测吞吐。
