LevelDB不支持直接存储C++对象，必须先序列化为字节流再写入，反序列化时需严格匹配字段顺序与类型，并校验数据完整性以避免未定义行为。
LevelDB 本身不支持直接存 C++ 对象，必须序列化
LevelDB 是键值对存储，只认 std::string 或原始字节（const char* + size_t）。它完全不管你的 class Person 有没有成员函数、虚表或指针。直接把对象地址或 reinterpret_cast 成字符串塞进去，读出来就是野指针或未定义行为——运行时崩溃或数据错乱是常态。
真正能走通的路径只有一条：先序列化成字节流，再写入；读出后再反序列化还原对象。关键不是“怎么连 LevelDB”，而是“怎么安全地序列化”。
- 别用
memcpy(&obj, ...)或std::bit_cast—— 类有非 trivial 构造/析构、含指针、虚函数、对齐差异时必崩 - POD 类（纯数据、无构造函数、无虚函数、无私有/保护成员）可考虑
std::memcpy，但跨平台或升级编译器后仍可能因 padding 变化失效 - 推荐方案：用明确控制字段顺序和类型的序列化方式，比如
protobuf、msgpack，或手写serialize()/deserialize()成员函数
用 msgpack 手动序列化 std::string 成 LevelDB value 的典型流程
msgpack 轻量、无 schema、C++ 接口干净，比 protobuf 更适合简单对象。以一个 struct User { int id; std::string name; double score; }; 为例：
// 写入
User u{123, "Alice", 95.5};
msgpack::sbuffer buffer;
msgpack::pack(buffer, u.id, u.name, u.score); // 按固定顺序 pack 字段
<p>leveldb::Status s = db->Put(leveldb::WriteOptions(),
std::to_string(u.id),
leveldb::Slice(buffer.data(), buffer.size()));
注意三点：
立即学习“C++免费学习笔记（深入）”；
- key 用
std::to_string(u.id)而非reinterpret_cast，避免二进制 key 在迭代时排序异常 - value 传
leveldb::Slice(buffer.data(), buffer.size())，不是std::string(buffer.data(), ...)—— 否则遇到 \0 就截断 - msgpack 默认不支持
std::string的零拷贝，但buffer.data()是连续内存，可直接交由 LevelDB 管理
反序列化时必须严格匹配字段顺序与类型，且检查 msgpack 返回状态
读出 value 后不能假设它一定合法。LevelDB 不校验内容，网络传输、磁盘损坏、版本升级都可能导致字节流损坏。msgpack 解包失败会抛 msgpack::type_error 或返回空对象，不处理就会静默出错。
// 读取
std::string value;
leveldb::Status s = db->Get(leveldb::ReadOptions(), "123", &value);
if (!s.ok()) { /* 处理 key 不存在或 IO 错误 */ }
<p>try {
auto oh = msgpack::unpack(value.data(), value.size());
int id; std::string name; double score;
oh.get().convert(id, name, score); // 顺序、类型必须和 pack 时完全一致
User u{id, name, score};
} catch (const msgpack::type_error& e) {
// 日志记录 + 丢弃该条记录，不要让单条坏数据阻塞整个查询
}
- 字段顺序错一位（比如先 pack
name再id，却按id,name解），convert()可能不报错但赋值错乱 - 如果未来加字段，旧数据解包会失败——要么用 msgpack 的 map 格式带 key 名，要么在 value 前加 1 字节版本号做路由
- LevelDB 的
value是只读std::string，传给msgpack::unpack时需确保生命周期覆盖整个解析过程
性能敏感场景下，避免重复分配和 string 拷贝
高频写入时，每条记录都 new 一个 msgpack::sbuffer、再 copy 到 LevelDB 内部缓冲区，GC 和内存碎片压力明显。可复用缓冲区或预分配空间：
- 用
msgpack::sbuffer的reserve()预估大小（如id占 4 字节、name长度 + 1 字节长度前缀、score占 8 字节），减少 realloc - LevelDB 的
WriteBatch批量写入比单条Put快 10 倍以上，尤其配合sync=false（接受少量宕机丢数据） - 若对象字段极少且固定（如只有
int64_t timestamp+float32_t value），直接手写 memcpy 到预分配的std::array<char></char>，比 msgpack 快 2–3 倍，但失去可读性和扩展性
序列化格式的选择本质是权衡：msgpack 省心但多几字节开销；手写二进制紧凑但改字段就得全量迁移数据；proto 需要 IDL 和生成代码，适合长期演进的大系统。LevelDB 本身只是个可靠的字节数组保管员，它不管你怎么编码——但你得为编码的鲁棒性负责。
