Windows 10 上装 Redis，十个人能搜出八种教程，放在官网下载页又只看到 Linux 版本，很多新手第一反应是自己下错了地方。这不怪你，Redis 官方其实没有提供面向 Windows 的原生安装包，这个事我在本地开发机上折腾过好几轮，踩了不少坑之后才把几套方案的逻辑理顺。这篇文章直接把 Windows 10 下装 Redis 的路子全部铺开，对比三种主流方案，从第三方 Windows 移植版、WSL2 里跑 Linux 原版，再到 Docker 容器，每一步怎么做、为什么这么做、遇到问题怎么排查，一次讲清楚。
先说结论，方便你对号入座：如果你只是本地写代码、调接口，想赶紧起一个缓存服务验证逻辑，那就用第三方 Windows 原生版，解压双击就能跑；如果你想把本地环境和线上 Redis 版本保持一致，或者正在学习 Redis 的高级特性，建议走 WSL2；如果你同时维护多个项目、需要不同版本的 Redis 互不干扰，Docker 是最省心的。下面我按方案拆开细说。
1. 安装前的思路：为什么 Windows 上没有官方安装包
1.1 先认清 Redis 的跨平台现状
Redis 在设计之初就是以 Linux 为主要运行环境，官方发布渠道长期只提供 Linux 源码包和对应的二进制发行版。Windows 上出现的可执行文件，其实来自两条线：一是很多年前官方团队曾经做过一个针对 Windows 的移植分支，后来因为维护成本太高放弃了，版本一直停留在比较旧的 3.x；二是社区开发者基于旧分支继续维护的 Windows 编译版，常见的有 3.x、5.x，再往后就比较少了。
这带来的直接影响是，你在 Windows 上跑 Redis，本质上用的是“社区移植产物”，不是官方长期维护的版本。这个差异平时开发可能感觉不明显，但如果你打算把某个特性从本地迁移到生产环境，就得提前确认本地版本和线上版本的命令、内存淘汰策略、持久化行为是否一致。我见过 A 同学在本地用 3.x 调好的 Lua 脚本，推到生产环境(6.x)发现某些返回结构变了，脚本解析报错，折腾了一整天。
1.2 三条路线的取舍对比
在 Windows 10 下装 Redis，我把它分成三条主线，各有各的适用场景，没有绝对好坏，关键看你的约束条件。
| 方案 | 安装产物 | 优点 | 缺点 | 适合谁 |
|---|---|---|---|---|
| A：Windows 原生移植版 | exe/zip，redis-server.exe 直接跑 | 安装最快、零依赖、适合临时验证 | 版本普遍偏旧、非官方支持、部分模块缺失 | 本地快速测试、学习命令 |
| B：WSL2 + Linux 版 Redis | WSL 发行版内 apt 安装 | 官方版本、特性完整、和生产环境一致 | 需要开启 WSL、占用内存、自启配置略麻烦 | 想认真做开发的长期方案 |
| C：Docker Desktop 容器 | redis 官方镜像 | 干净隔离、多版本切换方便、可复现 | 需要装 Docker Desktop、网络参数有学习成本 | 多项目并行、需要环境隔离 |
我的个人建议是：临时用方案 A，长线开发用方案 B，项目多、版本杂用方案 C。下面每个方案我都会给出从零开始的完整步骤。
2. 方案A：Windows 原生版安装实操
2.1 下载、目录规划与版本识别
方案 A 的典型形态是一个压缩包，解压后里面包含 redis-server.exe、redis-cli.exe、redis-benchmark.exe、redis.windows.conf 等文件。下载时我建议搜索“redis for windows zip”这类关键词，认准社区常见的分发主页，不要随便从不明站点下载。拿到压缩包后先看文件名里的版本号，比如 redis-5.0.14 之类，尽量选 5.x 或更高一点的版本，3.x 对于很多新特性支持不到位，本地开发容易产生认知偏差。
解压路径一定要避开中文、空格和带特殊权限的目录，比如 C:\Program Files 这种路径在服务注册时经常因为引号问题出幺蛾子。我习惯建一个 C:\Redis 的目录，把压缩包内容全部解压进去，目录结构保持扁平，后续写命令、改配置都方便。
注意：下载后先不要把服务注册上去，第一次启动一定要用命令行方式前台跑，这样所有报错都会直接打印在终端里，肉眼可见。我遇到很多人上来就注册成服务，结果启动失败又不知道日志在哪，排查效率极低。
2.2 先以命令方式启动，验证基础配置
打开 cmd，切到 Redis 目录，执行：
redis-server.exe redis.windows.conf首次启动会看到类似这样的日志输出，说明 Redis 正在监听 6379 端口：
[12345] 01 Jan 10:00:00.000 # Warning: no config file specified, using the default config... [12345] 01 Jan 10:00:00.000 * Ready to accept connections这个时候再开一个 cmd 窗口，同样进入 Redis 目录，执行：
redis-cli.exe ping如果返回 PONG，说明服务已经正常起来了。接着可以快速做几个基础命令验证：
redis-cli.exe set mykey hello redis-cli.exe get mykey redis-cli.exe quit这步的目的不是测试 Redis 功能，而是确认你下载的这个移植版能够在本机正常运行，端口没被占用，命令能通。如果这一步就报错，先别往下走，把错误信息记下来，大概率是缺少 VC++ 运行库或者端口冲突，这部分我在最后的问题速查表里会详细讲。
2.3 手工优化 redis.windows.conf
前台跑通了，下一步就是把配置改成适合你开发环境的样子。用任意文本编辑器打开 redis.windows.conf，重点看下面几个参数。
第一个是 requirepass。
# 找到这一行 # requirepass foobared # 改成 requirepass YourStrongPassword很多教程说本地开发不用设密码，我强烈建议设。原因很简单：你的 Windows 开发机很可能连着公司内网或家庭路由器，6379 是个默认端口，局域网扫描工具一抓一个准。不设密码等于把 Redis 裸奔在网络上，万一被写入恶意数据或者被清空，你哭都来不及。本地设密码没有任何成本，只是每次连接多一行参数而已。
第二个是 logfile 和日志级别。
loglevel notice logfile "C:/Redis/redis.log"默认情况下 Redis 日志输出到终端，注册成服务之后终端没了，日志也就丢了。手动指定一个 logfile 路径，服务运行状态下出问题才有迹可循。注意这里路径分隔符用正斜杠或者双反斜杠，避免转义问题。
第三个是持久化策略。
Redis 支持 RDB 快照和 AOF 追加文件两种方式。默认 RDB 是开启的，配置里对应这几行：
save 900 1 save 300 10 save 60 10000含义是：900 秒内至少有 1 次写操作就触发快照；300 秒内至少有 10 次写操作触发；60 秒内至少有 10000 次写操作触发。如果你的开发场景是频繁写缓存，这些默认值够用。如果希望数据更安全，不容易丢，可以把 AOF 也打开：
appendonly yes appendfilename "appendonly.aof"AOF 会记录每次写操作，重启时回放，相比 RDB 快照方式丢数据的概率小很多。开发环境开 AOF 的好处是，你写的缓存数据在重启后还在，不用每次重新造数据。
第四个是内存上限和淘汰策略。
maxmemory 256mb maxmemory-policy allkeys-lrumaxmemory 是 Redis 能占用的最大内存，到了上限之后按照 maxmemory-policy 决定怎么处理新写入。allkeys-lru 的含义是：内存满了，优先淘汰最近最少使用的 key。开发机建议至少设置 256mb，太小的内存上限会导致 Redis 频繁淘汰数据，干扰你调试。如果你只是缓存一些很小的临时数据，也可以设置为 noeviction，即内存满了不再接受写入，直接报错返回，这样你至少能立刻感知到内存不足，而不是数据被悄悄淘汰。
第五个是 bind 地址。
bind 127.0.0.1默认只监听本机回环地址。这个默认值在开发环境不要动，除非你有明确的需求要局域网内其他机器连接。如果改了 bind，比如改成 0.0.0.0，等于暴露到整个局域网，必须和密码配在一起用，否则非常危险。
2.4 注册为 Windows 服务实现开机启动
前台跑通、配置改好之后，你可能不想每次开机都手动开个窗口，那就把 Redis 注册成 Windows 服务。
不同移植版注册命令略有差别，常见有两种形式。第一种是用 Windows 自带的 sc 命令：
sc create Redis binPath= "C:\Redis\redis-server.exe --service-run --service-name Redis" start= auto注意 sc 命令等号后面必须有空格，这是很多人踩过的巨坑。注册成功后启动服务：
sc start Redis第二种是移植版自带的参数，旧分支常见：
redis-server.exe --service-install redis.windows.conf --loglevel notice --service-name Redis redis-server.exe --service-start无论哪种方式，都要以管理员身份打开 cmd。注册完服务之后，可以在服务管理器里看到 Redis 服务，启动类型默认是自动，意味着开机自启。
这里有一个特别容易翻车的点：很多移植版解压目录里有两个配置文件，redis.windows.conf 和 redis.windows-service.conf。注册服务时如果用 redis-server.exe --service-install 命令，默认读取的是 redis.windows-service.conf，不是你刚才改的 redis.windows.conf。我见过有人密码写在 redis.windows.conf 里，服务启动后怎么连都说 NOAUTH，排查了半天才发现服务读的是另一个文件。解决办法很简单，要么把两个配置内容同步，要么在注册命令里显式指定用哪个配置文件。
2.5 卸载与日常管理
以后不想用了，卸载也简单，管理员 cmd 里执行：
sc stop Redis sc delete Redis然后删除整个 C:\Redis 目录即可。日常管理命令我整理成速查：
| 操作 | 命令 |
|---|---|
| 启动服务 | sc start Redis 或 net start Redis |
| 停止服务 | sc stop Redis 或 net stop Redis |
| 查看服务状态 | sc query Redis |
| 连接客户端 | redis-cli.exe -a 密码 |
| 测试连通性 | redis-cli.exe ping |
3. 方案B：WSL2 方式安装 Linux 原版
3.1 为什么我优先推荐 WSL2
如果你的 Redis 使用场景不只是本地临时缓存，而是要作为开发环境的一部分长期存在，我会建议你认真考虑 WSL2 这条路。理由有三个。
第一，WSL2 安装的 Redis 是 Linux 原生版本，来自官方 apt 源或其他官方维护渠道，版本和大多数 Linux 服务器保持一致。这意味着你在本地写的命令、测试的脚本，推到生产环境时行为几乎一致，不会遇到移植版特有的兼容性问题。
第二，WSL2 本质是一个轻量级虚拟机，但它和 Windows 共享文件系统、网络、剪贴板，日常使用体感上接近一个本地终端。Redis 装在里面，占用内存可以动态释放，不像传统虚拟机那样固定吃你几个 G 内存。
第三，WSL2 里不仅能跑 Redis，你以后的其他 Linux 工具链，比如新版本的 Python、Node、Nginx，都可以统一放在这个环境里，避免在 Windows 上反复折腾编译环境。
3.2 开启 WSL2 与安装 Redis
开启 WSL2 的步骤不复杂，但需要重启一次系统。Windows 10 版本需要 2004 以上，你可以在 cmd 里执行：
wsl --install这个命令会自动安装 WSL2 核心组件和默认的 Ubuntu 发行版。如果系统提示需要重启，就重启。重启之后打开 Ubuntu 终端，首次进入会要求设置用户名和密码，这是 Linux 账号，不是 Windows 账号，注意别混。
进入系统后，先更新软件源：
sudo apt update sudo apt upgrade -y然后用 apt 直接安装 Redis：
sudo apt install redis-server -yUbuntu 官方 apt 源里的 redis-server 版本可能不是最新版，但对绝大多数开发场景够用。安装完成后，这个版本的 Redis 不会自动启动，需要手动起：
sudo service redis-server start为什么用 service 而不是 systemctl？因为 WSL2 默认不启用 systemd，而 Redis 的启动脚本同时支持 init.d 方式，service 命令会代理到对应脚本。如果你在 WSL2 里执行 systemctl start redis，多半会报错“System has not been booted with systemd”，这不是 Redis 的问题，是发行版没有开启 systemd 支持，不要在这个坑里浪费时间。
启动后验证：
redis-cli ping看到 PONG 就说明这套环境已经可用了。配置文件位置在 /etc/redis/redis.conf，和 Windows 版的配置项大同小异，requirepass、appendonly、maxmemory 这些关键参数用同样的方式改，改完记得：
sudo service redis-server restart3.3 让 Windows 侧访问 WSL 里的 Redis
很多人卡在这一步：WSL2 里的 Redis 跑起来了，但 Windows 这边的可视化客户端连不上。原因在于 WSL2 使用虚拟网络，Redis 进程监听的地址未必是 Windows 能直接访问的 localhost，或者说转发规则不总是那么透明。
新版本的 WSL2 默认开启了 localhostForwarding，理论上 Windows 侧可以直接访问 localhost:6379 转发到 WSL2。但如果你改了 Redis 的 bind 配置，或者 WSL2 版本较旧，这个转发可能失效。我建议按下面顺序排查：
先在 WSL2 里查看 Redis 实际监听的地址：
sudo netstat -tlnp | grep 6379如果监听的是 127.0.0.1:6379，说明 Redis 只接受本机连接。此时从 Windows 侧能不能连，取决于 WSL2 的 localhost 转发是否生效。最简单的验证方式是 Windows cmd 里执行：
redis-cli -h localhost -p 6379 ping能通就继续用；不通的话，有两个选择。第一，改 Redis 配置文件，把 bind 127.0.0.1 改成 bind 0.0.0.0，同时在 WSL2 里通过wsl hostname -I查到 WSL 的 IP，Windows 客户端连这个 IP。这个方式的缺点是 Redis 会监听 WSL 网络的所有地址，如果你的 Windows 防火墙没有限制，局域网内也可能访问，所以必须设好 requirepass。第二，如果你不想让 Redis 暴露任何额外网络，又想要 Windows 客户端连接，可以考虑固定 WSL2 的 localhost 转发规则，或者干脆用 Docker 方案代替，反而省事。
3.4 开机自启与资源限制
WSL2 里的服务不像 Windows 服务那样可以在服务管理器里设置自动启动。如果你希望 Windows 开机后 WSL2 里的 Redis 自动运行，有几种思路。
第一种，创建 Windows 计划任务，触发器选择“登录时”或者“系统启动时”，操作里写：
wsl.exe -d Ubuntu -- sudo service redis-server start注意，WSL2 启动时需要 sudo 密码，这会让计划任务执行不顺利。你先在 WSL2 里执行sudo visudo，给当前用户添加一条免密执行 redis 启动脚本的权限，然后再写计划任务，就可以实现全自动启动。
第二种，启用 WSL2 的 systemd 支持。新版 WSL2 支持在每个发行版的 /etc/wsl.conf 里加一行：
[boot] systemd=true然后在 Windows 侧执行wsl --shutdown再重新进入发行版，之后就可以用 systemctl 管理服务了，自启脚本也可以通过 systemctl enable redis-server 来设置。这个方案更贴近真实 Linux 服务器，我推荐。
资源限制方面，WSL2 默认可能占用你整个物理内存，你可以在用户目录下创建一个 .wslconfig 文件来控制：
[wsl2] memory=2GB swap=2GB localhostForwarding=true这个 .wslconfig 只对 WSL2 生效，放在 C:\Users\你的用户名 下。改完执行：
wsl --shutdown再重新打开 WSL2，配置才会生效。
4. 方案C：用 Docker Desktop 跑 Redis 容器
4.1 什么时候选 Docker
Docker 方案放到第三个讲，不代表它不重要，反而是因为它在某些场景下是最优解。如果你同时维护多个项目，有的项目要求 Redis 5.x，有的要求 7.x，用 Windows 原生版装来装去简直灾难。Docker 的镜像隔离机制让每个容器可以有自己独立的版本和配置，互不干扰。
另一个场景是可复现性。Docker 容器可以通过 docker-compose 文件完整描述 Redis 的版本、端口映射、存储卷、环境变量，团队成员拉下来直接跑，不会出现“我这边好好的，你那边怎么连不上”的本地环境差异。
当然，Docker 方案的代价是你需要先安装 Docker Desktop，启动时它会在后台运行一个 Linux 虚拟机，内存占用比方案 A 大。好在 Docker Desktop 可以在设置里限制内存使用量，比如限制在 2GB 以内，对日常开发影响不大。
4.2 快速运行一个带持久化和密码的 Redis
安装 Docker Desktop 之后，打开终端执行。第一次拉取镜像可能比较慢，耐心等等。下面这条命令可以直接跑起一个单机 Redis：
docker run -d \ --name redis-demo \ -p 6379:6379 \ -v redis-data:/data \ redis:7 \ --requirepass YourPassword \ --appendonly yes逐项拆解一下：-d是后台运行；--name redis-demo是容器名字；-p 6379:6379把宿主机的 6379 端口映射到容器的 6379 端口，这样 Windows 这边的工具就能通过 localhost:6379 连接；-v redis-data:/data创建一个名为 redis-data 的存储卷，容器重启后数据还在；redis:7是镜像名和标签，表示 Redis 7.x 版本；--requirepass和--appendonly是启动时直接覆盖默认配置，不需要进容器改 conf。
启动之后验证连接：
docker exec -it redis-demo redis-cli -a YourPassword ping返回 PONG 说明一切正常。想在 Windows 侧测试，同样可以在本地跑 redis-cli：
redis-cli -h localhost -p 6379 -a YourPassword ping如果你的项目团队倾向于用 docker-compose 管理，那就写一个 docker-compose.yml：
version: "3.8" services: redis: image: redis:7 container_name: redis-demo ports: - "6379:6379" volumes: - redis-data:/data command: ["redis-server", "--requirepass", "YourPassword", "--appendonly", "yes"] restart: unless-stopped volumes: redis-data:以后只需要：
docker compose up -d就能复现一个完全一样的 Redis 环境。这个文件建议放到项目仓库里，别人克隆下来一条命令就能起。
4.3 常见坑：端口冲突、重启策略、防火墙弹窗
Docker 方案看着清爽，踩坑也不少。最常见的是端口冲突。如果你的开发机之前已经用方案 A 装过 Redis，6379 被占用，docker run 时会直接报错“port is already allocated”。处理办法有两个：一是先停掉原有 Redis 服务，释放端口；二是换个映射端口，比如-p 6380:6379，然后客户端连 localhost:6380。第二种更省事，尤其是你暂时不想停掉原有服务的时候。
第二个坑是容器重启策略。默认情况下，Docker 容器在 Docker Desktop 重启后不会自动启动，加上--restart unless-stopped参数可以解决。上面 docker run 命令里我特意在最后忘了写，这里提醒你务必加上，否则你电脑重启后 Redis 不会自动拉起，排查半天才发现是容器没启动。
第三个坑是 Windows 防火墙弹窗。第一次运行 docker run 映射端口时，Windows 可能弹出允许防火墙访问的提示，建议选择允许在专用网络使用。如果你手滑点了取消，之后可能发现局域网内其他机器访问不到，但本机正常，不要浪费时间重新装容器，直接去防火墙放行 Docker 进程即可。
第四个坑是关于数据卷的误解。很多人以为-v redis-data:/data之后，Redis 的配置也会被持久化。实际上这个卷只存 Redis 的数据文件，比如 RDB 快照和 AOF 日志，不存配置文件。如果你想自定义 redis.conf，需要把它挂载进容器，这个已经超出基础使用范畴，这里不展开，等有需要再深入。
5. 安装后的功能验证与常见问题排查实录
5.1 五分钟功能验证清单
不管你用上面哪个方案装好 Redis，我建议都跑一遍下面这套验证命令，确认环境是真的可用的，而不是仅仅“进程在跑”。
先用客户端连上：
redis-cli -a 你的密码 ping正常返回 PONG。接着测基础读写：
redis-cli -a 你的密码 set username zhangsan redis-cli -a 你的密码 get username redis-cli -a 你的密码 expire username 60 redis-cli -a 你的密码 ttl usernamettl 返回 60 左右，说明过期时间设置生效了。再确认密码保护真的有效，故意不输密码访问：
redis-cli set test 1这时候应该看到 NOAUTH Authentication required，说明密码已经生效。再看一眼内存和键数量：
redis-cli -a 你的密码 info memory redis-cli -a 你的密码 dbsize最后做个简单的性能兜底，用自带的压力测试工具确认本机 Redis 没有明显的系统级瓶颈：
redis-benchmark -n 10000 -c 50 -a 你的密码这个命令是发 10000 个请求，50 个并发连接，正常情况下本机 Redis 的 QPS 应该能达到几万甚至十几万。如果只有几千而且响应时间很不稳定，先检查是不是内存不足、CPU 降频或者杀毒软件在扫描，别急着怀疑 Redis 配置。
5.2 常见问题速查表
把我在实战中遇到过的典型报错整理成一张表，每个问题都给排查方向和解决动作。
| 现象 | 可能原因 | 排查和解决 |
|---|---|---|
| 启动 redis-server.exe 一闪而过 | 缺少 VC++ 运行库 | 安装运行库后重试 |
| redis-cli 提示 connection refused | 服务没启动/端口不对 | 确认进程监听端口，netstat -ano 检查 6379 |
| 服务注册失败，提示服务名无效 | cmd 没有管理员权限 | 右键管理员运行 cmd |
| 连接后提示 NOAUTH | 设置了密码但没带 | redis-cli -a 密码 连接 |
| 写入数据后重启丢失 | RDB/AOF 未配置 | 检查 save 参数和 appendonly 是否开启 |
| WSL2 里 systemctl start redis 报错 | WSL2 未启用 systemd | 使用 service redis-server start |
| Docker run 提示端口被占用 | 6379 已被其他进程占用 | 改宿主映射端口为 6380 |
| Windows 客户端连不上 WSL2 里的 Redis | localhost 转发失效或 bind 限制 | 排查监听地址，必要时设置 bind 0.0.0.0 并加密 |
| 内存满了数据被清空 | maxmemory-policy 设置不当 | 调整策略为 noeviction 或调大 maxmemory |
5.3 我个人踩过的几个坑
第一个坑是下载来源不正规。早期我图省事，在一个看着像官方但实际是第三方聚合站下载了个 Windows 版 Redis，解压之后发现连 redis-cli.exe 都没有，只用 server 包跑起来，后面想敲命令还得另找一个 cli。后来我学乖了，下载前先看文件数字签名和发布页面上的版本更新日志，而且只从社区公认的几个分发渠道下，绝不在不明网站碰运气。
第二个坑是服务方式启动时配置文件读错。我第一次把 redis.windows.conf 里的密码改好了，注册服务时没注意命令默认用的是 redis.windows-service.conf，结果服务自动启动了，密码却一直没生效，客户端连上去照样能操作。那时候我还以为是服务缓存了旧配置，各种重装，最后才发现是两个文件内容不一致导致的。这个坑很坑，也很典型，写在这里希望大家避开。
第三个坑是 WSL2 方案里的网络转发问题。我按照旧教程在 WSL2 里把 Redis 的 bind 改成 0.0.0.0，然后 Windows 侧连 WSL 的 IP，确实能通。但后来某次更新系统后，WSL 的 IP 变了，Windows 侧配置的客户端地址也跟着失效，排查了很久才明白 IP 是动态的。如果你不想折腾，就保持默认 bind 127.0.0.1，并依赖 localhostForwarding 规则；如果你要跨机器访问，优先考虑设置静态 IP 或者直接上 Docker，别在 WSL IP 上硬磕。
第四个坑是 Docker Desktop 未启动导致的误判。有几次我以为 Redis 容器挂了，执行 docker run 一直报错，后来才发现 Docker Desktop 根本还没启动，命令行只是提示无法连接 Docker 守护进程。这个错误信息很容易让人误解为镜像有问题，其实原因在 Docker 环境本身。养成习惯：遇到 docker 命令异常，先看 Docker Desktop 是否正常运行。
写在最后的个人经验
在 Windows 10 下装 Redis，方式多不代表随便选一个就行，关键还是看你到底想让它承担什么角色。临时验证代码逻辑，Windows 原生版最快；日常开发环境，我建议直接上 WSL2，提前熟悉 Linux 环境没有坏处；多项目并行、版本隔离要求高的时候，Docker 的收益最大。我自己现在的组合是：主力开发用 WSL2 里的 Redis 7，偶尔需要对比老版本行为时，docker run 起一个临时 5.x 容器，用完之后直接删掉，宿主机器干干净净。最后再啰嗦一句：不管选哪种方案，密码、持久化、内存上限这三个配置项一定要确认好，它们决定了你的 Redis 是趁手工具还是数据炸弹。
