Redis不支持直接存储C++对象，必须序列化为字节流（如JSON、Protobuf或自定义二进制）再以字符串写入；因redisCommand仅接受const char*，传struct指针会导致截断、乱码或崩溃，且POD限制、ABI差异、指针成员等问题使裸内存拷贝不可靠。
不能直接存 C++ 对象到 Redis Hash，必须序列化为字节流（如 JSON、Protocol Buffers 或自定义二进制格式），再以字符串形式写入；Redis 本身不理解 C++ 类型，也不支持对象直存。
为什么 redisCommand 传 struct 指针会崩溃或乱码
Redis 客户端（如 hiredis）的 redisCommand 接口只接受 const char* 类型的值参数。若你把 &my_obj 强转成 char* 传进去，实际发送的是内存地址处的原始字节 —— 这既不是合法字符串（可能含 \0），也缺乏类型元信息，服务端只会当普通二进制 blob 存，且极大概率在第一个 \0 就截断。
- struct 成员含指针（如
std::string、std::vector）时，直接 memcpy 会拷贝野地址，反序列化必然崩溃 - 不同编译器/ABI 下结构体内存布局（padding、对齐）不一致，跨语言或跨平台读取不可靠
- Redis Hash 的 field 是字符串，value 也必须是有效字符串（或二进制安全的
std::string_view）
推荐序列化方式对比：JSON vs Protobuf vs 自定义二进制
选哪种取决于你的场景重点：可读性、性能、跨语言需求还是体积。
-
JSON（用 nlohmann/json）：适合调试和简单对象，human-readable，但解析慢、体积大、不支持私有成员或函数指针；需手动定义
to_json/from_json，嵌套深时易出错 -
Protobuf（.proto + libprotobuf）：强契约、高效、跨语言，但需额外构建步骤（
protoc编译）、生成代码略重；适合长期演进的微服务间通信 -
自定义二进制（
memcpy+std::bit_cast）：仅适用于纯 POD 类型（无虚函数、无指针、无 std 容器），速度快体积小，但零兼容性 —— 一旦字段增删或类型变（如int→int64_t），旧数据全废
示例（JSON 序列化一个用户对象）：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
nlohmann::json j = {
{"id", user.id},
{"name", user.name},
{"score", user.score}
};
std::string json_str = j.dump();
redisCommand(redis_ctx, "HSET user:%d info %s", user.id, json_str.c_str());
用 hiredis 写入 Hash 的关键细节
别只关注序列化，hiredis 调用本身也有坑：
-
HSET命令参数顺序必须严格：key → field → value；多个 field/value 要用HSET key f1 v1 f2 v2格式，不要拆成多次调用（性能差、非原子） - value 字符串若含空格、引号或二进制字节，必须用
redisCommand的格式化接口（如"%b"）或提前 escape，否则命令解析失败 - 连接必须是
REDIS_REPLY_STATUS类型响应才表示成功；忽略redisGetReply返回值会导致错误静默丢失 - Hash key 建议带业务前缀（如
user:），避免命名冲突；field 名统一用 snake_case，别混用驼峰
真正难的不是“怎么塞进去”，而是“怎么保证下次能原样拿出来并正确解释”。序列化协议一旦定下，就锁死了数据格式兼容性边界 —— 改一个字段类型，就得考虑所有存量数据的迁移路径。
