根本原因是C风格字符串依赖'\0'作为结束标记，而char数组若未显式以'\0'结尾，printf("%s", arr)会持续读取后续内存直至遇到随机'\0'，导致乱码、信息泄露或崩溃；std::cout同理，若传入非空终止字符指针，行为未定义。
char数组没加\0，printf或cout输出乱码
根本原因是C风格字符串依赖\0作为结束标记，而char数组若未显式以\0结尾，printf("%s", arr)或std::cout 会一直读内存直到碰上偶然的<code>\0，结果就是输出不可控的乱码甚至崩溃。
常见触发场景：char buf[10]; strcpy(buf, "hello");——"hello"占5字节，但strcpy会复制6字节（含\0），这里没问题；但换成memcpy(buf, "hello", 5)就完蛋，buf里只有'h','e','l','l','o'，后面是未初始化垃圾值。
- 声明时直接初始化：
char buf[10] = "hello";（编译器自动补\0） - 手动补
\0：buf[5] = '\0';（前提是数组足够大且你清楚长度） - 用
strncpy要自己收尾：strncpy(buf, "hello", sizeof(buf)-1); buf[sizeof(buf)-1] = '\0'; - 避免裸用
memcpy处理字符串，除非你明确控制长度并手动置零
用std::string替代char[]能彻底避开这个问题
std::string自己管理内存和长度，不依赖\0，cout 输出的是逻辑内容，不会越界。它不是“更高级的写法”，而是从根本上消除了C字符串的终结符陷阱。
注意点：
立即学习“C++免费学习笔记（深入）”；
- 从C字符串构造
std::string是安全的：std::string s = "hello";或std::string s(buf);（此时buf仍需有\0，但仅限构造时） - 获取C风格指针用
s.c_str()，返回值保证以\0结尾，可放心传给printf等C函数 - 不要对
s.data()做%s输出——C++11前data()不保证结尾\0，虽然后续标准已统一，但习惯上优先用c_str()
调试时怎么快速确认是不是\0缺失导致的乱码
别猜，直接看内存。在GDB里用x/10cb arr（显示arr起始10个字节的十进制值），观察最后是否为0；或者用printf("len=%zu\n", strlen(arr));，如果返回值远大于你预期的字符串长度，基本就是没\0。
- 用
strlen前确保数组已初始化，否则未定义行为（比如char buf[10]; strlen(buf);——buf全是随机值） - VS下开启运行时检查（/RTCs）能捕获部分越界读，但不报
\0缺失，它只管访问非法地址 - Clang/GCC加
-fsanitize=address对越界读敏感，但同样不检测逻辑上的\0缺失
结构体里的char name[32]字段容易被忽略初始化
这是实战中最隐蔽的坑：结构体成员如果是定长char[]，声明时不初始化，后续只填了部分内容（比如person.name[0] = 'A'; person.name[1] = 'l';），忘了person.name[2] = '\0';，打印时就会把后面29个字节全当字符串输出。
- 结构体定义后立即用
{0}初始化：Person p = {}; // 全零初始化，包含name所有字节 - 用
memset(&p, 0, sizeof(p));（注意不是sizeof(p.name)） - 填充后立刻封尾：
strncpy(p.name, input, sizeof(p.name)-1); p.name[sizeof(p.name)-1] = '\0';
\0不是约定，是协议；漏掉它就像HTTP响应头里少写Content-Length——接收方只能靠猜，而猜错的代价是乱码、崩溃或安全漏洞。 
