如果你在搜索引擎里输入“Redis下载”，大概率会先进到 Redis 官网，然后在下载页面翻半天也找不到 Windows 安装包——这是几乎所有 Windows 新手都会踩的第一个坑：Redis 官方压根不发布 Windows 版。别急，这不代表 Windows 上没法用 Redis，只是你需要从几条不同的路里选一条走。作为经历过“官网找不到包、下载站装到捆绑软件、服务注册失败、防火墙连不上、日志刷爆磁盘”这一整套流程的人，我准备把 Windows 装 Redis 的完整思路一次说清楚，内容包括第三方移植版的下载安装、注册成 Windows 服务、配置文件调整、常见踩坑排查，以及更接近生产环境的 WSL2 方案。这篇文章适合刚接触 Redis、想在 Windows 本机学习和跑小项目的同学，也适合需要在纯 Windows 服务器上把 Redis 当正式服务维护的同行。
1. 先搞清楚：Redis 官网没有 Windows 版，装之前有几条路可选
很多人第一步就卡在“去哪下载”。Redis 官方（redis.io）从诞生起就面向 Linux 设计，安装页面只提供 Linux、macOS 等平台的二进制包，没有 Windows 版。根本原因倒不是 Linux 比 Windows 好，而是 Redis 的核心代码大量依赖 Linux 系统特性，比如 I/O 多路复用用的 epoll、做 RDB 持久化时的 fork 子进程机制，这些在 Windows 上要么没有、要么实现方式完全不同。官方开发者不想为了 Windows 单独维护一套移植分支，所以干脆不提供。
1.1 为什么很多人还是能在 Windows 上装成功
因为 Windows 上的 Redis 基本都是“第三方移植版”。做这件事的比较有名的仓库有 tporadowski/redis、redis-windows/redis-windows 等，他们把 Redis 源码改一遍，编译成能在 Windows 下直接运行的 .exe。还有微软自己在很多年前维护过一版 Redis for Windows（3.x 时代），但早就停止更新了，现在不建议再去下那个老古董。
另外两条更“正统”的路子是：用 WSL2 装 Linux 子系统，在 Ubuntu 里通过 apt 安装官方编译的 Redis；或者用 Docker Desktop 跑一个 Redis 容器。这两条路都没有“Windows 移植版”的兼容风险，更接近生产环境。
1.2 几条主流方案的横向对比
| 方案 | 本质 | 适合场景 | 上手难度 | 版本更新 | 生产可用性 |
|---|---|---|---|---|---|
| 第三方移植版 zip | Windows 原生编译 | 本地学习、临时测试、轻量工具 | 最低 | 滞后于官方，常见停在 5.x / 7.x | 一般 |
| MSI 安装包 | 移植版打包成安装程序 | 不想敲命令，想直接装成服务 | 低 | 同移植版 | 一般 |
| WSL2 + apt | Linux 子系统运行官方版 | 开发环境、要求与生产一致 | 中 | 随 Ubuntu 源及时更新 | 较好 |
| Docker Desktop | 容器方式运行镜像 | 习惯容器化开发的团队 | 中 | 镜像更新方便 | 较好 |
| Memurai | 商业 Windows 原生兼容实现 | 纯 Windows 服务器生产环境 | 中 | 商业持续维护 | 较好，但社区版有功能限制 |
1.3 我给你的选型建议
如果只是自己学着玩、写个 demo、验证功能，用 zip 移植版就够了，两分钟跑起来，不折腾。如果想把它当成一台开发机上的常驻服务，并且后面要研究 Lua 脚本、集群、主从这些稍微高级的功能，建议直接上 WSL2，这样行为和 Linux 服务器一致，避免你后来要部署到线上时才发现“Windows 版的命令行为跟官方不一样”。
如果公司服务器是纯 Windows，不允许装 Docker 和 WSL2，那只能在 Memurai 和移植版之间选。Memurai 兼容性更好、有商业支持，但社区版有并发连接数等限制；移植版免费，但你得自己接受它更新慢、部分特性缺失的现实，并且做好数据备份。
2. 最简单的跑法：下载 zip 移植版，五分钟让 Redis 在本机跑起来
先用最省事的方式把 Redis 跑起来，这是理解后续所有操作的基础。跟着步骤走，别跳步。
2.1 下载前必须注意的“版本甄别”
去 GitHub 搜上述仓库，进 Releases 页面下载 Redis-x64-xxx.zip。这里提醒一句：不要在乱七八糟的下载站下载所谓的“Redis 一键安装版”，我见过不少下载站把捆绑软件和 Redis 打包在一起，装上之后浏览器主页都被改掉。GitHub 的 release 页面虽然界面朴素，但它是干干净净的官方发布渠道。
版本选择上有讲究。早期常见的 tporadowski 版本停在 5.0.x，虽然稳定，但确实老旧。后来社区维护的 redis-windows 仓库提供了 7.x 甚至更高版本，功能更全，比如更好的 Stream 支持、ACL 权限控制。我的建议是直接选你能看到的最新稳定 7.x 版本，毕竟 5.x 和 7.x 在命令兼容性上已经有了不少变化，没必要一开始就学旧版本。
2.2 解压到固定目录，不要解压到下载文件夹
解压时选一个稳定的路径，比如C:\Redis或D:\Tools\Redis。路径不要带中文、不要带空格，原因后面注册服务的时候你就会明白。很多人图方便直接解压到桌面，后面做服务、配日志、数据持久化时各种奇葩问题都会冒出来。
解压完成后，目录里应该有这些关键文件。
- redis-server.exe：服务端主程序
- redis-cli.exe：命令行客户端
- redis-benchmark.exe：性能压测工具
- redis.windows.conf：默认配置文件（前台运行会用这个）
- redis.windows-service.conf：服务运行时的配置文件，后面重点改这个
2.3 前台启动与第一个读写验证
在解压目录里打开 cmd（普通权限就行，当前暂时不涉及服务注册），执行：
cd /d C:\Redis redis-server.exe redis.windows.conf看到 Redis 的 ASCII logo、版本号和端口 6379 提示，说明启动成功。这个窗口会一直占着，不要关它，它就是 Redis 服务本身。
然后另开一个 cmd，进入同样的目录，执行：
redis-cli.exe ping如果返回PONG，恭喜，你的 Redis 已经能提供服务了。再试一下写入和读取：
redis-cli.exe set author "iwanghong" redis-cli.exe get author能返回你设置的值，说明基本读写流程没问题。这种“前台启动”方式适合临时测试，但只要一关窗口，Redis 服务就停了，电脑重启后也不会自动恢复，所以要继续往下看如何注册成服务。
2.4 黑窗口一闪而过是怎么回事
很多人第一次双击 redis-server.exe，窗口闪一下就没了，然后觉得“Redis 是不是坏了”。其实窗口闪退说明启动失败，但错误信息来不及看到。这时候不要双击，而是用 cmd 到目录里手动执行redis-server.exe redis.windows.conf，错误信息就会留在屏幕上。常见无非几种：端口 6379 被其他程序占用了；缺少 MSVC 运行库（报错提示 msvcp140.dll 找不到）；配置文件里写了不存在的路径；权限不足，特别是你把它解压到了需要管理员权限才能写的目录里。这些在第 5 章里会细说。
3. 把 Redis 变成 Windows 服务：开机自启的正确姿势
前台运行只适合临时试验。正式使用的时候，Redis 应该像一件基础设施一样在后台默默运行，开机自动启动，崩溃了还能看 Windows 日志定位问题。这就涉及到“注册服务”。
3.1 为什么要多此一举注册服务
因为前台窗口模式有几个硬伤：窗口关了就没了；电脑重启不会自动拉起；Redis 进程和 cmd 窗口绑定，容易手滑关掉。注册成 Windows 服务后，Redis 变成后台进程，由 Windows 服务管理器统一管理，可以设置开机自启，可以用net start、net stop控制，状态和报错也能在事件查看器里看到。
3.2 注册服务的完整命令与参数解释
首先要管理员身份打开 cmd：开始菜单搜 cmd，右键“以管理员身份运行”。然后在 Redis 目录下执行：
cd /d C:\Redis redis-server.exe --service-install redis.windows-service.conf --service-name Redis --port 6379这里拆开解释一下参数：
--service-install：告诉 redis-server 以安装系统服务模式运行，而不是启动服务进程redis.windows-service.conf：指定服务启动时要加载的配置文件，这个必填，别漏--service-name Redis：服务名，默认就叫 Redis，也可以改成 Redis6379 这种--port 6379：服务的端口，其实推荐写进配置文件，这里加参数只是演示命令行覆盖能力
执行后提示Redis successfully installed as a service.，说明注册成功。然后启动它：
net start Redis去任务管理器或者运行services.msc，能看到一个名为 Redis 的服务，状态为“正在运行”。为了确认它真的能工作，执行：
redis-cli.exe ping返回PONG，说明服务模式的 Redis 已经正常对外提供服务。以后想让电脑开机自动启动，在服务属性里把启动类型设为“自动”即可；安装时默认就是自动，一般不用改。
3.3 服务安装和启动失败的排查思路
我见过不少人在这个环节出问题，典型的有三种。
第一种：提示“服务名无效”或者权限不足。几乎都是忘记用管理员 cmd 了。普通权限执行安装命令，Windows 不会给你写服务注册表的权限。
第二种：服务虽然安装成功，但启动后马上停止。这种时候别瞎猜，用两个命令定位。先看服务配置对不对：
sc qc Redis会显示 BINARY_PATH_NAME，确认它指向的路径以及配置文件参数是不是你要的那个。再看系统日志：事件查看器 -> Windows 日志 -> 系统，筛选 Redis 来源的记录，错误信息一般写得很明确，比如“指定的端口已被占用”或“配置文件不存在”。
第三种：目录路径里有空格或中文。比如你把 Redis 放在C:\Program Files\Redis，注册服务时命令行解析可能会把路径截断。解决办法是给路径加英文双引号：
redis-server.exe --service-install "C:\Program Files\Redis\redis.windows-service.conf" --service-name Redis我个人的经验尽量选不带空格的目录，减少后续麻烦。
卸载服务的命令也放这里，以后有用：
net stop Redis redis-server.exe --service-uninstall --service-name Redis如果你想改服务启动参数，可以用redis-server --service-update，但更省心的做法是改配置文件，然后net stop Redis && net start Redis重启服务。
4. 配置这一步别跳过：密码、端口、持久化、日志一次调明白
跑起来只是第一步，真正让 Redis 稳定、安全、可运维的是配置文件。Windows 移植版里有两个配置文件，它们的区别必须搞清楚，否则你改了配置发现不生效，会非常崩溃。
4.1 配置文件选择：redis.windows.conf 和 redis.windows-service.conf 别搞混
前面提过，redis.windows.conf是前台启动时默认加载的；redis.windows-service.conf是服务模式下按你安装命令指定的。如果你用前台方式测试，改的是redis.windows.conf；如果已经注册成服务，服务读的是redis.windows-service.conf。
很多人的操作是：改完redis.windows.conf，重启服务，发现参数没变化，于是怀疑服务有问题。其实服务根本没读这个文件。所以动手改配置前，先用sc qc Redis看清楚服务实际加载的是哪个配置文件。
4.2 常用配置项和它们背后的原因
下面这份配置建议按顺序过一遍。用记事本或 VS Code 编辑redis.windows-service.conf，改完保存。
port 6379 bind 127.0.0.1 protected-mode yes timeout 0 requirepass 你的密码 appendonly yes appendfilename "appendonly.aof" save 900 1 save 300 10 save 60 10000 maxmemory 256mb maxmemory-policy allkeys-lru logfile "D:/RedisLog/redis_log.txt" dir "D:/RedisData" databases 16port：监听端口，默认 6379。如果本机端口被占用，可以改成 6380 等。bind 127.0.0.1：只允许本机访问。如果你要局域网内其他机器连，需要改成bind 0.0.0.0，但前提是把requirepass设好，否则等于裸奔。protected-mode yes：这是 Redis 默认的“自我保护”机制。在没有密码而且没有显式绑定非回环地址时，它会拒绝外部连接，防止 Redis 被放到公网后被人扫到并注入数据。requirepass：设置访问密码。有密码之后，redis-cli 连接必须redis-cli -a 你的密码或先auth 你的密码才能执行命令。appendonly yes：开启 AOF 持久化，每次写命令都会追加到日志文件，比 RDB 更能减少数据丢失。save 900 1等：RDB 快照触发条件，900 秒内有 1 次写操作、300 秒内有 10 次写操作等。maxmemory：限制 Redis 最大内存，防止它吃光整台机器。设置后还要配淘汰策略。maxmemory-policy allkeys-lru：内存满了以后，按 LRU 算法淘汰最近最少使用的 key，这是最常见的生产配置。logfile：日志文件路径。Windows 下建议用正斜杠，比如D:/RedisLog/redis_log.txt，避免反斜杠转义问题。dir：RDB 和 AOF 文件存放目录。默认可能是当前目录，但服务模式下当前目录是系统目录，找起来很麻烦，不如显式指定。databases：默认 16 个库，索引 0-15，项目里一般都用 0 号库，这个保持默认就行。
改完后重启服务：
net stop Redis net start Redis然后验证：
redis-cli.exe -a 你的密码 ping如果返回 PONG，说明密码、认证流程都正常。
4.3 客户端连接时报错的常见对照
| 现象 | 原因 | 处理方式 |
|---|---|---|
| NOAUTH Authentication required | 服务端设了密码，客户端没带密码 | redis-cli -a 密码 连接 |
| ERR Client sent AUTH, but no password is set | 服务端没设密码，客户端却发了 AUTH | 去掉 -a 参数，或删掉 requirepass |
| 服务重启后配置未生效 | 改错了配置文件 | sc qc Redis 确认服务实际加载的文件 |
| 连接超时 | 端口不对、bind 限制或防火墙拦截 | netstat 查端口，检查 bind，放行防火墙 |
还有一些可视化客户端，比如 Redis Desktop Manager、Another Redis Desktop Manager、RedisInsight，配置连接时填入 host、port、password 即可。可视化工具最大的价值是看 key 分布和查看某个 key 的内部结构，平时调试能省不少事，但生产环境操作我建议还是用 redis-cli 命令行，防止手滑删数据。
5. 实测踩坑记录：我把在 Windows 上遇到的所有坑一次性说完
前面是标准流程，但现实中总会遇到各种“教科书上没写”的情况。这一章我把自己在 Windows 上实际踩过的坑完整捋一遍，重点是排查过程的思路，不是只给答案。
5.1 端口被占用：不是 Redis 的错，但 Redis 背锅
有一次我双击 redis-server.exe，窗口一秒闪退，当时我怀疑是配置文件写坏了。后面学聪明了，用 cmd 前台启动，屏幕上明确提示Could not create server TCP listening socket *:6379: bind: No error，然后告诉你端口被占用。
排查链路的正确姿势是：
netstat -ano | findstr 6379 tasklist /fi "pid 进程号"第一步看 6379 端口到底被谁占着，第二步看这个 PID 对应什么进程。我曾经发现是另一个 Redis 实例占着端口，也可能是某个开发工具的缓存服务。解决办法要么把占用进程关掉，要么干脆给新 Redis 换端口，改配置文件的port参数。
经验是：排查任何“启动不了”的问题，先看端口，再看配置，最后才怀疑 Dll 和环境。不要凭感觉乱改。
5.2 双击闪退或黑窗一闪而过：让错误信息多停留几秒
双击 redis-server.exe 闪退的另一个常见死法，是缺少 VC++ 运行库。Windows 移植版编译时依赖微软的 MSVC 运行库，系统里没有的话直接弹个“找不到 msvcp140.dll”的框，程序退出。很多人看到这个第一反应是“重新下载 Redis”，实际上是环境问题。解决办法是去微软官网下载并安装 Visual C++ Redistributable for Visual Studio 2015-2022 x64，装完再启动。
排查闪退问题，永远用“前台运行 + 看控制台输出”的方式：
redis-server.exe redis.windows.conf --port 6380临时用另一个端口起一个前台实例，如果它能正常启动，就说明原实例的问题大概率是端口冲突；如果它也闪退，说明配置文件有问题，比如dir指向的目录不存在，或者logfile路径没有权限。
5.3 中文乱码问题：数据没坏，是终端编码没对上
Windows 的 cmd 默认使用 GBK 编码，而 Redis 的数据很多是 UTF-8。你用redis-cli在 cmd 里执行get 中文key，屏幕上可能会显示乱码。很多朋友第一次遇到，以为数据存坏了，慌得不行，其实数据本身是完好的，只是终端显示层的编码不一致。
处理方法：在 cmd 里先执行chcp 65001，把代码页切到 UTF-8，再连 redis-cli，中文就能正常显示。如果你用 Redis Desktop Manager 这类图形化客户端，一般不存在这个乱码问题，它默认按 UTF-8 解析。需要特别提醒的是：前台窗口的服务日志如果出现中文乱码，同样先考虑编码问题，不要急着把日志文件删掉重来。
5.4 局域网访问连不上：从 bind 到防火墙的完整排查链路
这是我曾经被问到最多的问题：“明明本机redis-cli ping正常，为什么局域网其他电脑连不上？”这个问题的排查链路是固定的，按顺序走：
第一步，在本机查 Redis 实际监听的地址：
netstat -ano | findstr 6379看监听地址是127.0.0.1:6379还是0.0.0.0:6379。如果是前者，说明bind 127.0.0.1限制了只能本机访问，外部当然连不上。需要把配置文件里bind改成0.0.0.0或注释掉，然后重启服务。
第二步，确认是否设置了密码。protected-mode yes且无密码时，Redis 只允许回环地址访问。这是安全机制，不是 bug。改成允许局域网访问时，必须设密码。
第三步，如果 bind 和密码都没问题，那就是 Windows 防火墙拦住了入站 6379 端口。需要在“Windows Defender 防火墙 -> 高级设置 -> 入站规则 -> 新建规则”里，新建一条“端口”规则，协议选 TCP，端口填 6379，操作选“允许连接”，作用域按你的网络环境选择，然后在“配置文件”里勾选你要应用的网络类型。
这里有个安全提醒：6379 端口一旦暴露到不可信网络，Redis 极容易被勒索软件和挖矿程序扫描攻击，现实中被入侵的案例非常多。只允许可信内网访问，并且一定要设强密码，不要在公网裸奔。
5.5 服务突然挂掉的排查姿势
Windows 服务模式下 Redis 崩溃的原因通常隐藏得比较深。第一次遇到时，我一度以为是移植版不稳定，后来才发现是我的配置有问题。
排查顺序是：先用sc query Redis看服务当前状态；然后去事件查看器的“系统”日志找 Redis 相关 Error；接着看配置文件里指定的logfile最后几十行。绝大多数情况能直接定位到原因，比如 AOF 文件损坏、内存耗尽被系统杀掉、appendonly和dir路径指向了不可写位置、以及配置文件写入了非法参数导致启动失败。
很多“服务崩了”其实不是 Redis 自己崩的，而是 Windows 重启或目录权限变化导致的。所以配置里dir和logfile指向的目录一定要提前建好并确认权限，别等服务起不来才想到去检查目录。
5.6 同名服务冲突与卸载残留
如果你反复安装卸载，可能遇到“服务名已存在”的提示。这是因为服务卸载时没有停干净，或者上次安装异常中断，服务注册表里残留了同名条目。解决方式：
sc delete Redis用管理员 cmd 执行即可。然后再跑一次redis-server --service-install。这个坑在没有清理习惯的人身上经常出现，养成“改配置前备份、删服务前先 stop”的习惯，能省掉很多时间。
6. 往深走一步：更接近生产环境的 WSL2 + Redis 方案
如果你已经决定长期在 Windows 上搞 Redis，我建议你把 WSL2 方案认真考虑一下。这也是微软官方比较推荐的思路：Windows 里跑一个轻量 Linux 虚拟机，Redis 在 Linux 里以官方原生方式运行。这样一来，你在开发机上看到的行为和生产服务器完全一致，不会出现“Windows 版有、Linux 版没有”的语法差异。
6.1 WSL2 的安装准备
管理员身份打开 PowerShell，执行：
wsl --install这个命令会帮你启用“虚拟机平台”和“适用于 Linux 的 Windows 子系统”两个 Windows 功能，然后默认安装 Ubuntu，装完需要重启电脑，重启后再打开 Ubuntu 终端，按提示设置一个用户名和密码。
如果电脑没有开启 BIOS 虚拟化，WSL2 会起不来，需要进 BIOS 开启 Intel VT-x 或 AMD-V。这一点在旧电脑上比较常见，装之前先确认。
6.2 在 Ubuntu 里安装并启动 Redis
进入 Ubuntu 终端，执行：
sudo apt update sudo apt install redis-server -y安装完成后，直接启动：
sudo service redis-server start注意，WSL2 默认没有完整的 systemd 初始化系统（除非你手动开启），所以很多人执行systemctl start redis会报错。用service redis-server start才是眼前可行的方式。验证：
redis-cli ping返回 PONG，说明官方版本 Redis 已经在 WSL2 里运行。你可以在/etc/redis/redis.conf里改requirepass、protected-mode这些配置，改完重启服务。
6.3 Windows 程序如何连接 WSL2 里的 Redis
WSL2 有个挺方便的特性：Windows 的127.0.0.1能直接访问 WSL2 里监听的端口。也就是说，你在 Windows 里的 Redis Desktop Manager 或编程语言客户端，直接连127.0.0.1:6379就能访问到 WSL2 里的 Redis。前提是 WSL2 里的 Redis 确实监听在127.0.0.1，也就是配置里的bind默认值，别改成奇怪地址。
如果发现 Windows 连不上，先更新 WSL：wsl --update，再检查 WSL2 内 Ubuntu 的 Redis 监听状态：
ss -tlnp | grep 6379把输出和redis.conf里的 bind 对照一下，基本就能定位。
6.4 让 WSL2 里的 Redis 开机自启
WSL2 的启动时机和 Windows 服务不一样，它是在你打开 Ubuntu 终端时才启动子系统。想让 Redis 在 Windows 启动后自动运行，可以在 WSL2 的/etc/wsl.conf里加入：
[boot] systemd=true然后在 Ubuntu 终端执行：
sudo systemctl enable redis-server sudo systemctl start redis-server这样 WSL2 启动时就会带着 systemd 一起启动，Redis 作为 systemd 服务被拉起来。改完 wsl.conf 后需要执行wsl --shutdown再重新打开 Ubuntu 才生效。
顺便说一句，如果你已经装了 Docker Desktop，还有一个更偷懒的方案：一条命令跑一个官方 Redis 容器。
docker run -d --name redis -p 6379:6379 redis:7.2主从测试、临时起多个实例也非常方便。缺点就是 Docker Desktop 吃内存比较大，对老电脑不友好，而且容器里的数据默认放在容器内部，需要挂载数据卷持久化，否则容器一删数据全没。
6.5 什么时候该从移植版切到 WSL2
我的判断标准很简单：如果你发现自己在 Windows 移植版上开始研究 ACL 权限、Lua 脚本、主从复制、集群这些进阶功能，或者你要把系统部署到生产环境，这时候就别在移植版上继续磨了，直接切 WSL2。移植版适合“快速跑通”，不适合“深入研究”。你自己算一笔时间账：在移植版上摸索一个功能，发现文档里的命令不适用，再回头查是不是版本问题，来回折腾的时间早就超过你装好 WSL2 的时间了。
就我个人而言，日常在 Windows 上做 Redis 开发和验证，现在已经默认用 WSL2 方案了。移植版我还会留一份，纯粹是为了给同事快速演示、临时起一个服务排查问题，因为它真的够快、够省事。装 Redis 这事本身不难，难的是你判断应该用哪条路、出了问题知道去哪里找日志。把前面这几章内容消化掉，Windows 环境下的 Redis 基本不会成为你的路障。
