hiredis的rediscontext不能跨线程共享，因其内部socket fd、读写缓冲区、错误状态等资源非线程安全；多线程并发调用rediscommand或redisgetreply必然导致缓冲区错乱、c->errstr被覆盖或段错误。
hiredis context 为什么不能跨线程共享
因为 redisContext 内部维护了 socket fd、读写缓冲区、错误状态等非线程安全资源，hiredis 官方明确不保证线程安全。多个线程同时调用 redisCommand 或 redisGetReply 可能导致缓冲区错乱、c->errstr 被覆盖、甚至段错误——这不是概率问题，是必然行为。
每个线程独占一个 redisContext 是最简方案
适用于线程数固定、连接数可控的场景（比如 worker 线程池）。关键动作必须做全：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 线程启动时调用
redisConnectWithTimeout，传入明确的struct timeval（例如{1, 500000}表示 1.5 秒） - 连接后立刻检查
c->err，不只是判断c == nullptr；认证失败或 DB 不存在时c非空但c->err != 0 - 线程退出前必须调用
redisFree(c)，否则 socket 和内存泄漏 - 不要在析构函数里“悄悄” free——线程可能已 detach，析构时机不可控
用连接池避免频繁建连开销
高并发下反复 redisConnectWithTimeout + redisFree 会吃掉大量系统资源（TIME_WAIT、fd 耗尽）。连接池的核心逻辑是复用 redisContext*，但要注意：
- 池中每个
redisContext*必须绑定到**单一线程**使用，不能“借出再还回”给别的线程 - 每次从池取 context 后，先用
redisSetTimeout设置读写超时（比如{0, 200000}表示 200ms），防止某次命令 hang 住整个线程 - 执行完命令后，不立即
redisFree，而是归还给池；归还前建议发个PING检查连接是否还活，断了就丢弃 - 池本身要用线程安全容器（如
std::mutex+std::queue），但锁粒度要小——只锁“取/还”操作，不锁命令执行
二进制数据和错误处理在线程上下文里更易出错
多线程环境下，redisReply 的生命周期管理容易被忽略，尤其涉及二进制：
- 存二进制必须用
%b，例如redisCommand(c, "SET %b %b", key, key_len, val, val_len)；用%s会导致 \0 截断 - 取二进制时别写
std::string(reply->str)，得用std::string(reply->str, reply->len)——reply->str可能含 \0，且长度以len为准 - 每次
redisCommand后必须调用freeReplyObject(reply)；漏掉一次，在循环中就会累积泄漏 - 如果命令返回
REDIS_REPLY_ERROR，reply->str才是真实错误信息（如"NOAUTH Authentication required"），不是c->errstr
%b 用法、以及 freeReplyObject 的强制调用，这三点在压测时最容易暴露——往往表现成偶发的段错误或内存持续增长，而不是直接报错。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
