结构体未初始化就序列化发送会导致敏感数据泄露。因C++不自动清零成员，malloc内存非零，未赋值字段残留旧数据（如密钥），padding字节亦含随机内容；应使用值初始化、显式擦除或字段级序列化。
结构体未初始化就序列化发送，敏感字段残留内存值，是真实存在的高危漏洞。这不是理论风险——只要结构体里有未显式赋值的成员（尤其是 char 数组、int、指针），而你又直接 memcpy 或按字节打包发送，那上一次分配该内存块时留下的旧数据（可能是密钥、密码、临时 token）就会一并发出。
struct 成员未初始化就 memcpy 发送
这是最常见也最容易被忽略的泄露路径。C++ 不会自动清零栈/堆上的 struct 成员，malloc 返回的内存也不保证为零（calloc 才保证），new 更是只调构造函数、不填零。
- 典型错误：定义
struct AuthPacket { char token[64]; int seq; };，然后AuthPacket pkt; sendto(..., &pkt, sizeof(pkt), ...);——token数组内容完全随机，可能含前一个用户残留的密钥 - 即使用了
std::memset(&pkt, 0, sizeof(pkt))，也要注意：若结构体含虚函数表指针或非 POD 类型成员（如std::string），memset会破坏对象状态，引发未定义行为 - 正确做法：对 POD 结构体，优先用
AuthPacket pkt{};（值初始化，零初始化所有成员）；非 POD 则必须逐字段赋值或提供安全的序列化接口
序列化前未擦除敏感字段（如 key、nonce）
有些字段本就不该发出去，但开发者误以为“没赋值=空”，或者“发完就丢”，结果字段仍驻留在 struct 实例中，下次复用时被意外发走。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 场景：一个
SessionContext对象反复用于不同用户，其中char session_key[32]在首次使用后未主动清零，后续仅覆盖部分字节，尾部残留旧 key - 危险操作：
std::memcpy(buf, &ctx, sizeof(ctx))直接拷贝整个对象，不管哪些字段已过期 - 安全做法：在序列化前加显式擦除逻辑，例如
explicit_bzero(&ctx.session_key, sizeof(ctx.session_key));（Linux）或SecureZeroMemory(&ctx.session_key, sizeof(ctx.session_key));（Windows）；避免用std::fill或普通memset，它们可能被编译器优化掉
结构体含 padding 字节且未控制填充内容
结构体成员间存在 padding 字节，这些字节不参与语义，但会被 memcpy 一起发出去——而 padding 区域的内容完全不可控，可能来自任意前序内存操作。
立即学习“C++免费学习笔记（深入）”；
- 验证方法：用
offsetof和sizeof检查实际布局，例如struct { uint8_t a; uint64_t b; };中a后通常有 7 字节 padding - 不能依赖
__attribute__((packed))或#pragma pack彻底解决：它可能破坏对齐、影响性能，且不消除所有 padding（尤其含位域或复杂嵌套时） - 可靠方案：禁用直接内存拷贝，改用字段级序列化（如手动写入每个有意义字段到 buffer），或使用
std::byte+std::span显式控制输出范围，跳过 padding 区域
真正难防的不是“怎么清零”，而是“哪一块该清、哪一块不该碰、哪一块根本不能碰”。POD 结构体可以安全 memset，但一旦混入虚函数、std::string、std::vector 就立刻失效；explicit_bzero 只能清指定区域，漏掉一个字段就等于开门揖盗。最稳妥的防线，是让敏感数据从不出现在可序列化的结构体里——用独立生命周期管理，发前复制+立即擦除，而不是指望结构体自己“干净”。
