strlen 传 c_str() 需防空指针和生命周期失效：string 为空或指针未初始化/已释放会崩溃；临时对象的 c_str() 在表达式结束即失效；data() 与 c_str() 在 c++17+ 语义一致但意图不同，仍推荐 c_str() 用于 c 接口。
为什么 strlen 传 std::string::c_str() 还要小心空指针？
因为 std::string 对象本身可能为空，但更常见的是你手动管理的 char* 指针根本没初始化或已被释放。strlen 一遇到 nullptr 就直接崩溃，它不检查指针有效性。
- 安全做法：用前先判空 ——
if (ptr && *ptr)，而不是只靠strlen(ptr) > 0 -
std::string的.empty()和.length()是常量时间、空安全的，不用怕 - 混用时别假设
c_str()永远有效：如果string是临时对象（比如函数返回值），c_str()指针在表达式结束就失效
strcpy 为什么比 std::string::assign 更容易越界？
strcpy 完全不关心目标缓冲区大小，只认源字符串末尾的 \0；而 std::string 自动管理内存，扩容、拷贝、析构全由类自己控制。
- 写死缓冲区大小（如
char buf[256]）+strcpy(buf, src)→ 源字符串超长就覆盖栈上其他变量 -
std::string s; s.assign(src, len)或直接s = src，内部会按需分配，不会越界 - 若必须用
strcpy，优先换成strncpy，但注意它不保证目标以\0结尾 —— 得手动补 - 现代 C++ 中，所有需要手动算长度、申请空间、复制字节的场景，基本都该用
std::string替代
什么时候非得用 strlen/strcpy，不能用 string 成员函数？
主要出现在与 C 接口打交道的地方：系统调用、老库 API、嵌入式环境、性能敏感且已知长度固定的短字符串处理。
- 例如
open(<code>path.c_str(), O_RDONLY) —— 系统调用只收const char*，这时c_str()是必要桥接，不是“替代” - 又如
snprintf(buf, sizeof(buf), "%s:%d", name.c_str(), port)—— 格式化进固定大小缓冲区，string没法直接替代这种控制 - 但别为了“省一次构造”在循环里反复调
c_str()：只要string不变，c_str()返回值可复用；频繁构造新string才是真开销 - 嵌入式或裸机环境若禁用 STL，那
strlen/strcpy就是唯一选择 —— 但得自己确保所有输入可控
string::data() 和 c_str() 在传给 C 函数时能互换吗？
不能默认互换。C++11 起 c_str() 保证返回以 \0 结尾的字符串，data() 在 C++11 之前不保证结尾有 \0；C++17 开始两者语义一致，但习惯上仍用 c_str() 表达“我需要 C 兼容字符串”。
- 调用
printf("%s", s.data())在 C++17+ 安全，但可读性差 ——c_str()更明确意图 - 如果函数声明为
void f(const char* s)且文档说“接受 C 字符串”，就用c_str()；如果它实际只读前n字节（如write(2)），data()+size()更合适 - 切记：
data()和c_str()返回的指针在string修改、移动或析构后立即失效
事情说清了就结束。最常被忽略的其实是生命周期 —— c_str() 拿到的指针不是“副本”，只是视图，一不留神就用着用着变成野指针。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
