std::string 读含 \0 数据不会自动截断，因其基于长度计数而非 \0 终止；但用 c_str() 传给 c 函数或 printf %s 会截断，须用 data()+长度或十六进制调试，构造时务必指定长度参数。
用 std::string 读含 \0 的数据不会自动截断，但得手动控制长度
很多人以为 std::string 和 C 风格字符串一样，遇到第一个 \0 就停——其实不是。std::string 是基于长度计数的，\0 对它只是普通字符。问题出在你怎么读、怎么传、怎么用。
常见错误现象：std::ifstream::read() 读进 std::string 后，用 c_str() 传给 C 函数，结果被提前截断；或用 operator 输出时只看到前半段——那是因为输出流碰到 <code>\0 就停了，不是 string 本身丢了数据。
- 读二进制/混合数据时，优先用
std::vector<char></char>或带长度的std::string构造：std::string(buf, size)，别依赖std::getline或operator>> -
std::string::data()返回的指针可含\0，但传给 C 接口前必须确认接收方支持长度参数（如write(2)），否则仍要避免裸传c_str() - 调试时别用
printf("%s", s.c_str())查看内容，改用循环打印每个字节的十六进制值
char[] 读 \0 数据必须自己记长度，不能靠 strlen
C 风格数组天然不存长度，一旦里面混了 \0，strlen、strcpy、printf %s 全都会错判边界。这不是“能不能用”的问题，是“用了就崩”的风险。
使用场景：对接旧 C 库、解析协议帧、处理内存映射文件——这些地方 <p>使用场景：对接旧 C 库、解析协议帧、处理内存映射文件——这些地方 <code>\0 很常见，且往往出现在中间。
- 永远别对含
\0的char*调用strlen；用事先保存的长度变量，或用std::span<const char></const>（C++20）封装 - 写入时避免
strcpy/strcat；改用memcpy+ 显式长度，或snprintf控制最大写入字节数 - 如果必须用
char[]当缓冲区，声明时留足空间，并在每次读写后更新有效长度变量，别和数组大小混淆
std::ifstream::read() 和 std::ofstream::write() 是最稳的二进制 I/O 组合
想安全读写含 \0 的文本或二进制块，绕开所有“文本模式”接口。Windows 下默认打开文件是文本模式，会把 \r\n 转成单个 \n，还可能误判 \0——必须显式指定 std::ios::binary。
性能影响几乎为零，但兼容性差在没加 binary 标志时，Linux 可能侥幸通过，Windows 必然出错。
- 打开文件务必加标志：
std::ifstream f("data.bin", std::ios::binary) -
read()不会自己加\0，也不会停在\0；但你要保证目标缓冲区够大，并检查f.gcount()获取实际读取字节数 - 写入前确认
write()的第二个参数是真实数据长度，不是strlen结果——这是最常踩的坑
从 char* 构造 std::string 时，千万别漏掉长度参数
写成 std::string s(p)（单参数构造）等于告诉编译器：“请按 C 字符串规则找结尾”，一旦 p 中有 \0，后面全丢。这个行为在调试时极难察觉，因为静态分析和编译器都不会报错。
容易被忽略的地方：第三方库返回的 const char* 常附带长度说明（比如 protobuf 的 ByteString::data() + size()），但人眼一扫就下意识当成普通字符串。
- 只要源头可能含
\0，一律用双参数构造：std::string s(p, len) - 若只有
char*没长度，且确定是纯文本，先用memchr扫一遍确认无\0再用单参构造——但不如直接上std::vector<char></char>省心 - 函数参数设计上，接收含
\0数据时，优先用std::string_view（C++17）或std::span<const std::byte></const>（C++20），逼调用方显式传长度
\0——而这两个判断，往往发生在不同人的代码交界处。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
