因为std::string和std::vector内部含指向本进程堆内存的指针，跨进程共享时指针在另一进程解引用会访问非法地址，导致崩溃或垃圾数据；必须用POD结构+显式序列化，如char[]配合长度字段。
为什么不能直接把 std::string 或 std::vector 放进共享内存
因为它们内部持有指向堆内存的指针，而每个进程的堆是隔离的。一个进程在共享内存里写入 std::string 对象时，它只存了 24–32 字节（小字符串优化后）或一个指针 + size + capacity；那个指针指向的是本进程堆上的某块内存，另一个进程映射同一段共享内存后，去解引用这个指针，访问的是自己进程里完全无关、甚至非法的地址——结果就是崩溃或读到垃圾数据。
同理，std::map、std::shared_ptr、任何含虚表或动态分配成员的类，都不可直接序列化进共享内存。这不是封装技巧问题，是操作系统内存模型决定的硬限制。
- 共享内存只保证“字节块物理一致”，不保证“对象语义一致”
-
sizeof(std::string)≠ 实际字符串长度，后者存在别处 - 即使两个进程用相同编译器、相同 STL 版本，也不能绕过堆隔离
变长数据的安全方案：用 char[] + 显式长度字段
核心思路是把变长部分作为紧邻结构体的连续字节存放，靠偏移和长度控制边界，不依赖任何运行时分配器。
例如定义一个消息头：
立即学习“C++免费学习笔记（深入）”；
struct MessageHeader {
uint32_t magic; // 校验用
uint32_t version; // 兼容性
uint32_t payload_len;
uint32_t timestamp;
};
写入时用 placement new 构造头，再把 payload memcpy 到紧随其后的地址：
char* shm_ptr = /* 映射起始 */;
MessageHeader* hdr = new (shm_ptr) MessageHeader{...};
memcpy(shm_ptr + sizeof(MessageHeader), payload_data, payload_len);
- 读取时先读
hdr->payload_len，再按偏移取后续字节，不调任何构造函数 - 必须确保整个结构 + payload 不超过共享内存总大小，且对齐满足
alignof(MessageHeader) - 避免使用
std::string::c_str()直接拷贝——它返回的指针仍指向私有堆
复杂对象怎么办：拆成 POD + 手动生命周期管理
所谓“复杂对象”，只要不含指针、虚函数、非 trivial 析构/拷贝，就能安全放进共享内存。判断标准很简单：能用 std::is_trivially_copyable_v<t></t> 和 std::is_standard_layout_v<t></t> 双重确认。
但多数业务类不满足。这时要主动拆解：
- 把逻辑层（算法、状态机）和数据层（纯字段）分离，只把数据层放入共享内存
- 用
union或std::array<uint8_t n></uint8_t>模拟可变布局，配合 tag 字段区分类型 - 若需多态行为，改用函数指针表或外部 dispatch，而非虚函数表（vtable 地址跨进程无效）
- 所有字符串字段统一替换为固定长度
char name[64]，末尾加 \0，读取时用std::string_view(hdr->name)
注意：哪怕对象是 POD，也要检查 padding 字节是否被初始化。未初始化的 padding 在 memcmp 或校验时可能引入随机差异。
最容易被忽略的一点：跨进程对象构造与析构顺序
你不能依赖 new / delete，因为它们调用的是当前进程的 operator new，分配的是本地堆。唯一安全的方式是 placement new + 显式调用析构函数（如果类型有 non-trivial 析构）：
MyPODStruct* obj = new (shm_ptr) MyPODStruct{...}; // OK，无副作用
MyNonTrivial* nt = new (shm_ptr + offset) MyNonTrivial{...}; // OK，但后续必须：
nt->~MyNonTrivial(); // 必须显式调用，不能靠 delete
更麻烦的是：谁来调？什么时候调？多个进程并发访问时，析构时机必须严格约定（比如仅由创建者负责，或通过引用计数+原子操作协调）。这点比数据布局更容易出错——它不会立刻崩溃，而是在某个升级或重启后，残留脏数据导致后续进程解析失败。
