c_str() 是获取 C 风格字符串的首选方法，返回合法 null-terminated const char*，零开销且语义明确；C++11 中 data() 不保证结尾 \0，C++17 起才与 c_str() 行为一致。
直接用 c_str()，别手写拷贝
绝大多数场景下，c_str() 就是你要的答案。它返回 const char*，指向内部连续存储的 null-terminated 字符串，可直接传给 C 函数（如 fopen、printf、strlen）。不需要额外分配内存，也不需要手动加 \0 —— 标准库已保证其有效性。
常见错误是看到“C 风格数组”就想着 new char[n+1] + strcpy，这纯属浪费：多一次堆分配、一次内存拷贝、一次析构管理，还容易忘 delete[]。
-
c_str()返回指针有效期仅到下次该std::string的非 const 成员函数被调用（如push_back、clear、甚至赋值），或对象析构 - 若需长期持有（比如跨线程、存入 C 结构体缓存），才考虑深拷贝；否则直接用，零开销
- 空字符串调用
c_str()仍返回合法指针，指向单个\0
data() 在 C++11 和 C++17 中行为不同
C++11 的 data() 不保证末尾有 \0，返回的是底层字符缓冲区首地址，但可能不 null-terminated；C++17 起，data() 和 c_str() 行为完全一致 —— 都返回 null-terminated 的 const char*。
所以如果你的项目必须兼容 C++11 编译器（比如某些嵌入式或旧工具链），data() 不能替代 c_str() 用于 C 接口；而 C++17+ 两者可互换，但语义上 c_str() 更明确表达“我要一个 C 兼容字符串”。
立即学习“C++免费学习笔记（深入）”；
- 检查编译器标准：
__cplusplus宏值 ≥201703L才能安全依赖data()的 null-termination - 即使 C++17+，也建议优先写
c_str()：代码可读性更强，避免同事误以为你在取“原始字节流” -
data()的非 const 重载（string::data()）在 C++17 后才允许修改内容，但改完不调用resize或reserve可能导致未定义行为
真要转成独立 C 数组？只在必要时 malloc + strcpy
只有当 C 接口会修改你传入的缓冲区（比如 gethostname(buf, len)），或你需要把字符串生命周期和 std::string 解耦（例如注册回调后原 string 已销毁），才需要真正复制一份。
此时别用 std::vector<char></char> 包裹再取 .data() —— 多一层间接、且 vector 默认构造不填 \0，容易遗漏；直接 malloc 或 new[] 更直白可控。
- 正确写法：
char* cbuf = new char[str.size() + 1]; std::strcpy(cbuf, str.c_str()); - 记得配对
delete[] cbuf;，或用std::unique_ptr<char></char>管理 - 用
strncpy要小心：它不保证目标以\0结尾，除非源长度 n；推荐std::strcpy+ 显式检查str.size()是否超限 - 性能上，这种拷贝是 O(n)，比
c_str()的 O(1) 慢一个数量级，别在循环里做
为什么 c_str() 几乎没性能损耗
现代 STL 实现（libstdc++、libc++、MSVC STL）普遍采用“短字符串优化”（SSO）或小缓冲区内置，c_str() 本质只是取成员变量地址，无函数调用开销、无分支判断、无内存访问异常。汇编展开后常是一条 lea 或 mov 指令。
有人测出 c_str() 比 data() 慢一点 —— 那通常是测试方法有问题：比如没关编译器优化、反复调用却没复用返回值、或者测的是 debug 版本。在 -O2 下二者指令完全一致。
- 不要为
c_str()做缓存（如存成局部const char* p = s.c_str()），除非你确定后续不会修改s；缓存本身不省事，反而增加理解成本 - 调试时如果发现
c_str()返回乱码，大概率是string对象已被析构，或正在被多线程并发修改 —— 这是生命周期问题，不是函数选错 - 第三方库若声明接受
const char*却偷偷保存指针并延后使用，那是它的 bug，不是你该用data()或拷贝的理由
真正要注意的从来不是选 c_str() 还是 data()，而是谁拥有那块内存、谁负责释放、以及那个指针到底能活多久 —— 这些问题藏在接口契约里，不在函数名里。
