简介面向在Windows平台开展C/C项目并希望接入Redis的开发者这份预编译的Redis客户端库将hiredis.lib、Win32_Interop.lib及相关头文件打包成套解决了在Windows下直接使用Redis客户端库的痛点省去从Linux环境移植、自行编译适配的繁琐环节。资源整体仅20个文件、6.9MB体积轻量且结构清晰以lib静态库和h头文件为核心同时带有exe小工具、dll运行组件及一份说明文本目录按x86/x64分别组织开发者可以按需选配。目前已有1700余人在CSDN学习下载是一套经过验证的Windows可用方案。具体来看每个架构下均包含Debug与Release两种配置运行库分别使用/MTD和/MT兼顾调试便利与发布性能hiredis作为Redis官方推荐的C客户端库可高效处理服务器回复Win32_Interop则补全Windows系统调用与兼容层使Redis能稳定运行在Windows环境中。借助这套库开发者可在Visual Studio等编译环境中直接链接调用快速实现Redis作为缓存、消息中间件或键值存储的核心功能连同附带的源码与说明文本还能深入理解hiredis的解析机制和Win32_Interop在系统调用、线程兼容等方面的适配细节无论用于实际项目交付还是研究Linux软件向Windows移植的工程实践都是高性价比的参考资料。 有人在群里问我“Windows 下有没有现成的 Redis C 客户端库能直接链接”我一开始想说“有vcpkg 一把梭”但看到它后面跟着“含 hiredis.lib、Win32_Interop.lib 及相关头文件”这句就明白了这不是随便装个包的事而是要把一套能稳定跑在 Windows 上的 Redis 客户端静态库真正编译出来、整理好、交给项目用。这套东西我前前后后折腾过好几次中间踩的坑不比写业务代码少今天把它完整捋一遍希望能帮到正在被 POSIX 函数和链接错误折磨的人。hiredis 是 Redis 官方的 C 语言客户端库本身是为类 Unix 环境设计的。Linux 下安装它几乎无脑make make install几分钟完事。但换到 Windows这套流程瞬间失效——hiredis 源码大量使用read/write/close/strcasecmp/ssize_t这类 POSIX 符号而 Windows CRT 和 Winsock 的命名规则与接口形态跟 Unix 完全不是一回事。直接拿源码编译光是头文件和链接错误就能让你怀疑人生。这时候就需要 Win32_Interop 这种桥接层把 POSIX 调用翻译成 Windows API才能让 hiredis 在 Windows 工具链里顺利活下来。这篇内容我会围绕以下几条线展开先讲清楚为什么 hiredis 在 Windows 下编译这么折腾、Win32_Interop 在其中扮演什么角色再交代我用的工具链和编译参数然后给出完整的编译步骤、最终交付的包结构最后用一个实际可运行的 C 示例演示怎么接入项目并把编译和链接阶段常遇到的报错整理成排查表。适合需要在 Windows 下做 Redis 客户端开发、想把 hiredis 静态库纳入现有 C/C 工程、或者对跨平台 C 库移植感兴趣的读者。1. 为什么这套库值得自己手动折腾一次1.1 hiredis 在 Windows 下难编译的根源在哪我们先明确一件事hiredis 不是“不愿意支持 Windows”而是它天生站在 POSIX 这一边。源码里随处可见unistd.h、sys/socket.h、getaddrinfo、close、read、write这些都是 Unix 环境下的标准接口。Linux 上一切理所当然Windows 上就成了拦路虎。具体来说有几个典型的冲突点include 头文件不兼容。sys/socket.h在 Windows SDK 中不存在对应功能分散在winsock2.h里两者不能简单替换。函数命名规则不同。Windows CRT 给很多 C 标准函数加了前导下划线比如read对应_readwrite对应_writeclose对应_closestrcasecmp对应_stricmp。套接字关闭语义不一致。Unix 里close()可以直接关闭 socket 描述符Windows 上必须用closesocket()用close()关 socket 会导致句柄泄漏甚至程序崩溃。类型定义缺失。ssize_t这种类型在老版本 MSVC 里没人定义编译时直接报 C2065 标识符未声明。这些问题单独拎出来任何一个都好解决但叠加在一起就构成了“看着简单、实际难搞”的局面。微软当年为了把 Redis 移植到 Windows维护了一套带 Win32_Interop 的适配层本质上是用一个兼容层把上述 POSIX 接口逐个映射到 Windows 原生实现。1.2 为什么不直接靠 vcpkg 一把梭我知道你现在肯定想问都什么年代了vcpkg install hiredis:x64-windows一行命令不香吗香确实香我在很多普通项目里也会这么干。但这个项目的情况不太一样目标环境中可能不具备在线安装条件需要把库文件直接随代码一起分发你手里可能有一批老代码它们依赖的是微软 Redis 分支里那个特定版本的 hiredis 和 Win32_Interop 接口面试或交付场景里别人给的就是一整个“编译好的库包”你需要理解里面每部分是谁、干什么用手动编译能让你完全掌控运行时库、优化选项、架构匹配绕开 vcpkg 默认配置和项目要求不一致的麻烦。所以我的观点是vcpkg 可以作为参考比对的“标准答案”但真正要输出一套包含 hiredis.lib、Win32_Interop.lib 和目标头文件的交付物手动编译一次是绕不开的你也能借此把所有兼容性问题彻底搞清楚。等这一步做完你会对链接器、静态库、运行时库这些概念有新的理解。2. 编译前的准备与工具链选择2.1 需要准备哪些东西这套流程完全在 Windows 上操作建议环境如下Windows 10 或 Windows 1164 位系统Visual Studio 2019 或 2022安装时勾选“使用 C 的桌面开发”工作负载Git用于拉取源码也可以用现成压缩包可选一个顺手的内网 Git 镜像方便在源码下载不顺畅时同步仓库不影响后续任何步骤。这里强调一个细节Visual Studio 必须装上“C 桌面开发”相关组件只装 VS Build Tools 也是可以的但没装 C 工具链后面cl.exe和lib.exe就根本不存在。我第一次编译时就栽在这上面打开开发者命令提示符后直接提示“不是内部或外部命令”后来检查发现是当时图省事只装了 C# 工作负载。2.2 Win32_Interop 到底是干什么的Win32_Interop 是这整套移植方案里最核心的“翻译官”。它提供了一组头文件和实现把 hiredis 代码里依赖的 POSIX 接口“改名换姓”成 Windows CRT 或 Winsock 对应的调用。实际操作中Win32_Interop.h里会包含类似这样的宏映射#define open _open #define read _read #define write _write #define close _close #define strcasecmp _stricmp同时针对 socket 相关的特殊处理微软的移植分支会在net.c等文件里额外做#ifdef _WIN32分支把close映射成closesocket把网络相关调用统一到 Winsock2 接口上。这样一来上层 hiredis 代码几乎不用大改就能在 Windows 下编译、链接、运行。顺带一提这个思路不只是为了解决 Redis 问题。很多 Unix 开源库想移植到 Windows都会走类似的“兼容头文件 宏映射 专用实现”路线。你搞懂了 Win32_Interop 的用法以后移植其他 POSIX 库也有章可循。2.3 版本和架构选择我把一切构架固定在两个维度上维度选择说明架构x64 为主兼容 32 位则额外编译一套现在的服务器和 PC 基本都是 64 位x64 是主场景老项目若依赖 32 位 DLL才需要 Win32 平台版运行时库静态链接使用 /MT库发布给他人使用时最好用 /MT 避免目标机器缺 VCRUNTIME140.dll编译器MSVC 默认工具集VS2019/2022 自带的 MSVC 均可用不建议用 MinGW 交叉混用尤其是“运行时库”这一项我实际踩过一次我用默认/MD编译的 lib 给另一个用/MT的项目链接结果链接器报了一堆LNK2038 mismatch detected for RuntimeLibrary。所以后面统一改成/MT问题一次性消失。这一个参数在最后集成阶段会反复遇到务必拿小本本记好。3. 亲手把 .lib 文件编译出来3.1 源码从哪里拿这里有两种拿法我直接给出推荐路径第一种从微软当年的 Redis for Windows 仓库获取整套源码。这是官方移植分支内部已经带了 hiredis 源码和 Win32_Interop 适配拿来就能编最省事。git clone https://github.com/microsoftarchive/redis.git克隆完成后进到仓库目录定位到 hiredis 和 Win32_Interop 的所在位置。不同历史分支的目录层次略有差别可能在deps/hiredis、deps/Win32_Interop也可能在src/hiredis、src/Win32_Interop建议以实际仓库为准。第二种单独拉取官方 hiredis 源码再手动复制 Win32_Interop 的头文件和实现过来套用。这种方式适合你想跟随最新版 hiredis 功能但对移植调整要求更高需要自己动手把宏映射加进去。我中途试用过一次发现 net.c 里的 Windows 兼容分支要自己补工作量不小所以后面还是回到第一种方案。3.2 编译 Win32_Interop.lib打开“x64 Native Tools Command Prompt for VS 2022”依次执行cd redis源码目录\deps\Win32_Interop cl /c /O2 /MT /DWIN32_LEAN_AND_MEAN Win32_Interop.c lib /OUT:Win32_Interop.lib Win32_Interop.obj这里解释下两个细节/O2表示启用速度优化发布库一般都用它/MT表示使用静态运行时库这样生成的 lib 在目标机器上不依赖 VCRUNTIME140.dlllib /OUT:的作用是把编译出的.obj打包成.lib这一步看起来简单但实际是静态库产物从“零散目标文件”走向“可分发交付物”的关键动作。如果源码目录里 Win32_Interop 依赖多个.c文件就逐个编译再一起打包命令类似cl /c /O2 /MT /DWIN32_LEAN_AND_MEAN Win32_Interop.c win32_helpers.c lib /OUT:Win32_Interop.lib Win32_Interop.obj win32_helpers.obj具体文件清单以你拿到的仓库为准。3.3 编译 hiredis.lib接着编译 hiredis 本体。进入 hiredis 源码目录后执行cd redis源码目录\deps\hiredis cl /c /O2 /MT /I.. /I..\Win32_Interop /DUSE_WIN32_INTEROP hiredis.c read.c sds.c async.c net.c lib /OUT:hiredis.lib hiredis.obj read.obj sds.obj async.obj net.obj这里的要点在于/I..和/I..\Win32_Interop分别指定了 hiredis 头文件所在目录、Win32_Interop 头文件所在目录/DUSE_WIN32_INTEROP定义了预处理宏这很重要hiredis 源码里只有看到这个宏才会启用#include Win32_Interop.h的路径编译对象包括net.c因为网络部分是 hiredis 的重头戏也是移植适配最密集的地方。编译结束后当前目录会出现一堆.obj文件和两个刚生成的.lib。如果你编译多个架构版本建议分别建x64和Win32两个输出目录不然.obj互相覆盖最后链接时会发现符号完全对不上。3.4 把交付包整理干净库这种东西光给一个.lib文件没有意义别人根本不知道怎么调。完整的交付包应该按下面的结构组织redis-windows-client/ ├── include/ │ ├── hiredis.h │ ├── read.h │ ├── sds.h │ ├── async.h │ ├── hiredis_win32.h 如源码中存在则一并带上 │ ├── Win32_Interop.h │ └── Win32_Interop_win32.h ├── lib/ │ ├── x64/ │ │ ├── hiredis.lib │ │ └── Win32_Interop.lib │ └── Win32/ │ ├── hiredis.lib │ └── Win32_Interop.lib └── README.md顺手写一个简短的README.md注明编译工具链版本VS2022、MSVC v143、运行时库类型/MT、适用架构x64/Win32以及链接时需要的附加依赖Ws2_32.lib。这些信息看起来琐碎但实际分发时比 100 行代码注释还有用。3.5 如果你想走捷径再用 vcpkg 对比验证一次如果你在普通场景下只需要一个能用的 hiredis不想折腾上面的过程可以这样vcpkg install hiredis:x64-windows-static注意这里的x64-windows-statictriplet表示静态链接、x64 架构和前面手动编译时用/MT的语义是对齐的。装完以后vcpkg 会自动配置好头文件和库目录你需要在项目属性里额外引用它生成的hiredis.lib。不过要提醒一下vcpkg 的官方 port 并不会帮你引入 Win32_Interop它默认提供的是完整适配后的 hiredis。用它做日常开发很舒服但如果你想精确复刻“含 hiredis.lib、Win32_Interop.lib”这套交付物、或者需要把它嵌入老旧工程手动编译仍是更可控的路线。4. 在 C/C 项目中正确接入这套库4.1 项目配置路径和依赖项假设我已经把上一节整理好的include/、lib/x64/目录放到项目旁边接下来打开 Visual Studio 项目属性页VC 目录 - 包含目录添加include路径VC 目录 - 库目录添加lib\x64路径C/C - 预处理器 - 预处理器定义确认添加USE_WIN32_INTEROP如果源码调用了该宏链接器 - 输入 - 附加依赖项追加hiredis.lib Win32_Interop.lib Ws2_32.lib其中Ws2_32.lib是 Windows 套接字编程的基础库没有它hiredis 里所有依赖 Winsock 的符号都链接不过去。这也是我最常碰到的一个坑只加了 hiredis.lib 和 Win32_Interop.lib忘了 ws2_32结果报了一堆__imp_WSAStartup、__imp_getaddrinfo未定义。4.2 一个能跑的最小示例下面是一段完整的 C 语言测试代码演示连接本地 Redis、写入一个键并读取回来#include winsock2.h #include stdio.h #include hiredis/hiredis.h int main(void) { WSADATA wsaData; if (WSAStartup(MAKEWORD(2, 2), wsaData) ! 0) { printf(WSAStartup failed\n); return 1; } redisContext *ctx redisConnect(127.0.0.1, 6379); if (ctx NULL || ctx-err ! 0) { if (ctx) { printf(Redis connection error: %s\n, ctx-errstr); redisFree(ctx); } else { printf(Cannot allocate redis context\n); } WSACleanup(); return 1; } redisReply *reply redisCommand(ctx, SET name hello); if (reply NULL) { printf(SET command failed: %s\n, ctx-errstr); redisFree(ctx); WSACleanup(); return 1; } freeReplyObject(reply); reply redisCommand(ctx, GET name); if (reply ! NULL reply-type REDIS_REPLY_STRING) { printf(GET name %s\n, reply-str); } freeReplyObject(reply); redisFree(ctx); WSACleanup(); return 0; }这段代码有几个细节值得注意必须在调用任何 Redis 命令之前执行WSAStartup这是 Windows 下使用 Winsock 的前置条件。面试时经常有人问“为什么我的 Windows 程序一跑 socket 就崩”八成是少了这一步每次拿redisCommand的返回值都要用freeReplyObject释放不然内存泄漏很隐蔽长时间跑容易把内存吃满连接失败时先判断ctx是否为空避免对空指针访问ctx-errstr。编译命令如果是命令行模式可以这样cl /MT test_redis.c /I include /link /LIBPATH:lib\x64 hiredis.lib Win32_Interop.lib Ws2_32.lib这样生成test_redis.exe运行之前确保本机或远程有个 Redis 实例在监听 6379 端口。我本地测试时用的是 Docker 起的 Redis简单方便不影响这套客户端库的验证。4.3 静态库与运行时库的匹配问题很多人在这一步才遇到真正的“连环坑”库是 /MT 编译的但自己的项目默认 /MD于是链接器开始报运行时库冲突。规则很简单/MT 编译的库使用者也必须尽量 /MT否则 CRT 符号交叉引用/MD 编译的库使用者应该保持 /MD项目里所有参与链接的静态库运行时库选项要尽量一致。如果你的项目受制于插件体系必须用 /MD那我建议回头重新编译一套 /MD 版的 hiredis.lib 和 Win32_Interop.lib各自打进lib\x64或lib\Win32子目录里并在 README 中标注清楚。用一个统一样式管理多套静态库后期切架构、切运行库都方便得多。5. 常见报错与排查技巧实录5.1 编译和链接期典型报错速查下面是我实际遇到过且频率很高的错误整理成一张速查表报错信息常见原因解决办法LNK2019无法解析的外部符号 read/write只链接了 hiredis.lib没链接 Win32_Interop.lib在附加依赖项里添加 Win32_Interop.lib无法解析的外部符号 __imp_WSAStartup缺少 Windows Socket 库添加 Ws2_32.libLNK2038RuntimeLibrary 不匹配库是 /MT 编译项目是 /MD或反之把项目的运行时库改为与库一致C1083无法打开包括文件 Win32_Interop.h头文件目录没加在包含目录里加 Win32_Interop 所在路径C2065“ssize_t”未声明老版本 SDK 缺少类型定义在代码或预编译头里补充typedef intptr_t ssize_t;或按平台用 SSIZE_TC2011结构类型重定义混用了 windows.h 和 winsock2.h强制在代码最前面#include winsock2.h并定义WIN32_LEAN_AND_MEAN链接报错找不到 libcmt.lib 或 libcmtd.lib使用了 /MT 但机器上缺少对应 CRT 库确认安装了“适用于最新 v142/v143 生成工具的 C MFCx86 和 x64”等可选组件所谓的符号导出决定代码能否顺利引用前者以上问题中头文件路径、库路径、运行时库一致性三项占了几乎九成问题。5.2 链接通过但运行时报错的排查思路链接成功后不等于万事大吉。程序一启动就崩或者在调用redisConnect时挂掉按下面顺序排查确认WSAStartup是否被调用过。很多人测试时直接抄了 Linux 示例代码根本没想到 Windows 需要先初始化 Winsock确认 Redis 服务端真的在跑且端口是 6379可以用命令行工具telnet 127.0.0.1 6379先手动验证一下确认本机防火墙没有拦截本地回环连接一般不会但公司安全软件有可能这么做如果getaddrinfo或 DNS 相关调用异常考虑是否用了过旧的 SDK 且没链接正确的Ws2_32.lib。我在一次项目里遇到过很诡异的情况程序在开发机一切正常拷到服务器上却报0xc000007b应用无法正常启动。查了半天发现是 32 位程序链接了 64 位静态库平台位数不匹配导致一系列符号调用错误。从那以后我每次拿到预编译库都会先跑一次dumpbin /headers看一眼machine (x64)还是machine (x86)十秒钟的事能省几小时排查时间。5.3 验证 .lib 文件的内部结构最后分享一个很实用的做法用dumpbin工具检查编译出的库文件是否正常。dumpbin /headers hiredis.lib头部信息里会明确显示目标机器类型、COFF 符号表结构等关键参数。再用dumpbin /exports hiredis.lib如果没有导出表说明它是个静态库这是正常现象如果希望某些函数被外部引用注意确认redisConnect、redisCommand、freeReplyObject这些符号确实存在。虽然看起来多了一步操作但这一步能让我这些年来在分发库、接手旧库时少踩无数坑。6. 从这次手工编译里我学到的东西第一点体会不要害怕“编译库”这种听起来底层的工作。它比写业务逻辑更枯燥但对理解工程整体环境特别有帮助。等你亲手把 hiredis.lib 和 Win32_Interop.lib 编出来再放到一个干净的 Visual Studio 工程里链接通过你脑子里的“平台差异”“运行时库”“符号解析”这些模糊概念会全部变得具体。第二点体会静态库的治理是门细活。不要只交付一个 .lib一定要配套头文件、README、编译参数说明最好按架构和运行时库分目录。这既是职业习惯也是让后来人少骂你的关键。第三点体会库的版本对齐真的很重要。hiredis 官方版本和微软移植分支版本存在差异如果你的项目后续要用到 hiredis 的新功能就得评估是升级整个移植分支还是自己往旧分支里搬到新代码。我一般建议线上长期维护的项目锁定一个已验证过的版本别频繁追新。在你开始动手之前我再给你一个可复现的快速验证流程先在一个干净目录里把源码下载好按第 3 节的命令把两个库编出来再用第 4 节的最小示例跑通连接然后写几个简单的 Redis 操作测一遍。整个过程熟练后大概一小时能完成第一次做可能半天但绝对值得。如果你最后发现某个版本编译不过去先别急着改源码。检查一下是不是源码里没有包含 Win32_Interop 的适配头文件或者编译命令行缺少-DUSE_WIN32_INTEROP宏。这属于 90% 以上“编译失败”的真正原因其次才是头文件路径、运行库匹配这些基础问题。最后再分享一个救命级的小习惯每次拿到别人给的预编译库我会先花三十秒执行dumpbin /headers和dumpbin /exports确认架构、运行时库、导出符号三件事然后再往项目里放。这一步看似多余实际上能帮你避开绝大多数“为什么链接不过”“为什么一运行就崩”的低级陷阱。希望这篇内容能让你少走我已经走过的弯路。本文还有配套的精品资源点击获取