说到 redis7 for windows 的安装，第一反应是官方下载页根本没有 Windows 分支。Redis 7 这个版本在 2022 年发布，带来了不少硬货，比如 Redis Functions、ACL 权限模型增强、Sharded Pub/Sub、以及更快的持久化机制，但官方始终没有提供原生 Windows 构建。正好我最近在一台 Windows 工作站上搭 Redis 7 环境，把目前主流的几种安装方式都过了一遍，从 WSL 到原生兼容服务再到 Docker 容器，全流程都有实操记录。这篇就把安装过程、选型思路、避坑点和日常运维细节一起整理出来。不管你是写业务代码的，还是做测试、搞数据分析的，只要想在 Windows 上把 Redis 7 用起来，按这条路走基本不会卡。
1. 先搞清楚 Redis 7 和 Windows 到底什么关系
1.1 官方为什么不提供原生 Windows 版本
很多人第一次搜 redis7 for windows 安装教程时都会懵：明明打开 Redis 官网下载页，列表里只有 Linux、macOS 的安装包，Windows 那一栏永远缺席。原因是 Redis 的核心依赖了 Linux 特有的系统调用，比如fork()实现后台持久化、epoll实现高效网络事件驱动。这些能力在 Windows 内核里没有对等实现，官方团队一直强调他们只在类 Unix 系统上做支持和测试，不想维护一套非官方移植分支。
过去几年里，确实出现过一些第三方贡献者搞的 Windows 原生移植版，但大多停留在 Redis 5.x、6.x，能跟进到 Redis 7 的很少，而且更新节奏、bug 修复都不稳定。我自己试过几个所谓“一键安装包”，有的是老版本换皮，有的安装完redis-server --version显示版本号不对，还有的干脆内置了服务后门逻辑——这个后面讲安全注意事项时会细说。所以在 Windows 上装 Redis 7，关键不是“下载哪个安装包”，而是“选择哪条运行路线”。
1.2 Windows 上运行 Redis 7 的三条主流路线
目前能在 Windows 上用上 Redis 7 的路径基本有三条：
- 通过 WSL 2（Windows Subsystem for Linux）装一个 Ubuntu 或 Debian 环境，在 Linux 子系统里跑官方原版 Redis 7。
- 使用第三方原生 Windows 兼容实现，比如 Memurai，它在 Windows 上以原生服务的形式实现 Redis 协议，新版已经跟进 Redis 7 协议特性。
- 用 Docker Desktop 拉取官方 Redis 7 镜像，以容器方式运行，底层其实仍然是借助 WSL 2 的 Linux 虚拟机。
这三条路各有各的适用场景。WSL 2 胜在还原度最高，Redis 官方任何新特性都能直接用；Memurai 则适合完全不想碰 Linux、只想装个 Windows 服务就能跑的人；Docker Desktop 适合需要在多个版本间横跳、快速做环境隔离的开发者。后面我会把三条路线都完整走一遍，然后给一个决策建议表。
2. 路线一：用 WSL 2 跑官方原版 Redis 7
2.1 安装 WSL 2 环境与 Ubuntu 发行版
WSL 2 是现在 Windows 上跑 Linux 最顺手的方案。要求 Windows 10 版本 2004 以上，或者 Windows 11。如果是比较新的系统，一条命令就能装好：
wsl --install -d Ubuntu-22.04装完之后系统会提示重启。重启后首次启动 Ubuntu，会让你设置一个 Linux 用户名和密码，这个是 Linux 子系统里的独立账号，跟 Windows 登录账号没关系。设置完建议先做两件事：
sudo apt update && sudo apt upgrade -y然后确认一下 WSL 版本是不是 2，因为 WSL 1 和 WSL 2 的网络模型、内核行为差异很大，Redis 在 WSL 1 下会遇到一些诡异的问题：
wsl -l -v输出结果里 NAME 列是 Ubuntu，VERSION 列必须是 2。如果不是，执行wsl --set-version Ubuntu-22.04 2。这里我强烈建议直接用 WSL 2，因为 WSL 1 是系统调用翻译层，Redis 7 对fork()和 IO 多路复用的依赖会导致编译或运行时的兼容问题。
2.2 在 Ubuntu 里安装 Redis 7 官方版本
Ubuntu 22.04 默认软件源里的 Redis 版本还停留在 6.0.x，所以直接apt install redis-server装出来不是 Redis 7。想要最新 7.x，需要先把 Redis 官方提供的软件源加进来。
这里有个细节值得说：Redis 官方团队维护了一个 PPA（Personal Package Archive），里面是最新稳定版。配置步骤大致是：
sudo apt install -y software-properties-common sudo add-apt-repository ppa:redis/redis sudo apt update sudo apt install redis-server安装完成后，用版本检查命令确认一下：
redis-server --version如果输出v=7.x.x就说明装对了。我装的时候最新稳定版已经到了 7.2 和 7.4 的维护版本，具体小版本号会随更新变化，但大版本是 7 就满足需求。
接着把 Redis 配置成开机自启。WSL 2 默认不一定启用 systemd，如果没有启用，可以手动改一下配置：
sudo tee /etc/wsl.conf <<EOF [boot] systemd=true EOF改完之后在 Windows 终端里执行wsl --shutdown，再重新进入 Ubuntu。之后就能用 systemctl 管理 Redis：
sudo systemctl enable --now redis-server sudo systemctl status redis-server如果这步执行时报单位找不到，大概率就是 systemd 没起来。老版本 WSL 的临时替代方案是sudo service redis-server start，但既然能用 systemd，建议还是直接启用。
2.3 配置 Redis 7 的密码、持久化与访问控制
官方原版 Redis 的默认配置非常保守，只允许本机回环地址访问，也不要求密码。如果是本机开发，默认配置够用；但只要想从 Windows 侧程序连接，或者希望数据重启不丢，就必须改配置。Redis 7 的配置文件在/etc/redis/redis.conf，最常用的三个修改点：
bind 127.0.0.1 -::1 protected-mode yes port 6379第一项是监听地址。只在本机开发的话，保持127.0.0.1就行。如果要从局域网其他机器访问，需要改成实际网卡 IP 或0.0.0.0，但这时候必须设置密码，否则相当于把 Redis 裸奔在网络上。然后设置访问密码：
requirepass your-strong-passwordRedis 7 密码不能为空，建议用强密码，尤其当你把监听地址暴露到局域网时。最后开启 AOF 持久化，避免重启丢数据：
appendonly yes appendfsync everysec我实际测试过，appendfsync everysec是性能和可靠性之间比较平衡的选择，每秒钟刷一次盘，最多丢一秒数据，对开发测试完全够。改完配置后重启服务：
sudo systemctl restart redis-server这里还有个容易踩的坑：改完bind和requirepass后，用redis-cli ping会报NOAUTH Authentication required。需要先认证：
redis-cli -a your-strong-password ping看到PONG就代表服务已经正常跑起来了。
2.4 Windows 程序如何连接 WSL 里的 Redis 7
这是很多初学者最容易卡住的地方。WSL 2 内部是一个轻量级虚拟机，有自己独立的 IP 地址，但微软在 WSL 2 里做了 localhost 转发，Windows 侧的127.0.0.1:6379会被自动转发到 WSL 里的 Redis 服务。也就是说，在 Windows 上的代码里直接写：
redis.Redis(host='127.0.0.1', port=6379, password='your-strong-password')就能连通。我实测了 Python、Java、Node.js 的客户端连接都没有问题。不过有一个细节要注意：localhost 转发只对从 Windows 访问 WSL 生效，如果局域网里的其他机器想连这个 Redis，仍然不能用 Windows 的局域网 IP，而是要在 Ubuntu 里查一下 WSL 的虚拟网卡地址：
ip addr show eth0拿到inet后面的地址，然后在 Windows 防火墙里放行 6379 端口，客户端才能连进来。
3. 路线二：用 Memurai 跑 Windows 原生 Redis 7 协议
3.1 Memurai 是什么，为什么值得考虑
如果实在不想碰 Linux、不想开 WSL，也不想为了本地调试装一个 Docker Desktop，那 Memurai 是第三条腿。它的定位是 Windows 原生 Redis 兼容服务，以 Windows Service 方式运行，随系统开机自启，行为上模仿 Redis 7 的协议和数据结构。比较关键的是它的开发者版对个人和开发用途免费，而且发布节奏会跟随 Redis 官方功能更新。
在实际选型时要注意：Memurai 并不是 Redis 官方代码的简单编译版，而是一个独立实现的兼容层。这意味着它支持绝大多数 Redis 命令与基础数据结构，但某些 Redis 7 的高级特性，比如 Redis Functions、Sharded Pub/Sub 的完整语义，可能没有完全对齐。如果你只是用 Redis 做缓存、队列、分布式锁、排行榜，Memurai 完全够用。如果要做脚本扩展或深度调优实验，那还是方案一的 WSL 原版更稳妥。
3.2 Memurai 安装与基础配置
Memurai 的官方网站提供了安装包下载。安装过程就是典型的 Windows 向导，一直下一步就行。安装完成后，服务列表中会多出一个 Memurai 服务，默认端口同样是 6379。需要注意，安装时如果当前机器 6379 端口已经被别的 Redis 实例占用，安装向导会提示端口冲突，这时候可以选择不配置默认服务，或者改端口，避免和已有实例互相打架。
安装之后，Memurai 的配置文件和 Redis 的格式很像，官方安装目录下一般会有类似memurai.conf的文件。常用的配置项无非还是那几个：
requirepass your-strong-password appendonly yes maxmemory 1gb修改配置后，在服务管理里重启 Memurai 服务即可。这里我的经验是：Memurai 的配置文件格式比原版 Redis 更接近 Windows 习惯，路径分隔符用反斜杠也没问题，但建议尽量保持正斜杠以兼容跨平台习惯。
3.3 Memurai 的验证与替坑清单
服务启动后，用 redis-cli 连接一下就能确认工作正常：
redis-cli -h 127.0.0.1 -p 6379 -a your-strong-password ping如果输出 PONG，说明 Memurai 已经正确响应 Redis 协议。进一步可以查看版本信息：
redis-cli INFO server这里要提醒一句：INFO server里显示的redis_version字段可能是7.0.x，但这是 Memurai 对外声明的兼容版本号，不等于你就拿到了官方 Redis 7 的全部能力。在我自己的测试中，常见的数据结构操作、事务、管道、Lua 脚本这些都能正常工作，但涉及模块（Module）加载这类和操作系统深度绑定的功能，Memurai 是不支持的。
另一个常见问题是 Memurai 默认服务账户权限有限，如果配置了appendonly持久化，数据文件写不到安装目录，日志会出现权限相关报错。解决办法是给 Memurai 服务指定一个对数据目录有写权限的 Windows 账户，或者在配置里把dir指到一个用户可写的目录，比如临时数据目录。这个坑官方文档不太会细讲，实际运维时却非常容易遇到。
4. 路线三：用 Docker Desktop 快速运行 Redis 7 容器
4.1 按需拉取官方镜像并启动容器
Docker 是另一个我在 Windows 上装 Redis 7 很推荐的方式，尤其是当你需要在 Redis 6 和 Redis 7 之间切换、或者同时跑多个不同配置的实例时，它的优势非常大。Docker Desktop 安装后会默认使用 WSL 2 后端，所以本质上仍然是把 Redis 跑在 Linux 虚拟环境里，但好处是镜像构建和运行环境完全由 Docker 管理，不需要自己维护 Linux 系统。
拉取官方镜像并启动容器，只需要一条命令：
docker run -d --name redis7 \ -p 6379:6379 \ -v redis7data:/data \ redis:7-alpine \ redis-server --requirepass your-strong-password --appendonly yes拆解几个参数的含义：-d表示后台运行，--name redis7给容器取名字，-p 6379:6379把容器的 6379 端口映射到 Windows 的 6379，-v redis7data:/data创建数据卷实现持久化，redis:7-alpine指定镜像，后面的redis-server ...是在容器启动时给 Redis 传启动参数。
启动后用 redis-cli 验证：
redis-cli -a your-strong-password -p 6379 ping这里有个细节值得讲：如果之前 WSL 里已经装了 Redis，或者 Memurai 也在监听 6379，那 Docker 端口映射会直接失败，报bind: address already in use。所以不同方案之间不要同时抢同一个端口，这点在同时折腾多套环境时要格外注意。
4.2 容器的持久化、自启与配置管理
用 Docker 跑 Redis 的一个常见误解是容器重启数据就没了。其实只要挂载了数据卷，数据就在。上面的-v redis7data:/data就是干这个用的。不过 Docker 卷默认是在 Docker 管理的虚拟磁盘里，普通用户不太好看数据文件，如果想直接管理文件，可以用本地路径替代：
docker run -d --name redis7 \ -p 6379:6379 \ -v D:/docker/redis7/data:/data \ redis:7-alpine \ redis-server --requirepass your-strong-password --appendonly yes这种方式数据文件直接落在 Windows 的D:\docker\redis7\data下，方便备份和检查。
关于开机自启：Docker Desktop 本身需要设置开机启动，容器再设置--restart unless-stopped，重启机器后 Redis 就会自动恢复：
docker update --restart unless-stopped redis7如果想改 Redis 配置，不建议在容器里手改文件，因为容器文件系统是临时的，一重建就没了。正确的做法是把自定义配置文件挂载进去：
docker run -d --name redis7 \ -p 6379:6379 \ -v D:/docker/redis7/conf:/usr/local/etc/redis \ -v D:/docker/redis7/data:/data \ redis:7-alpine \ redis-server /usr/local/etc/redis/redis.conf这样配置文件在 Windows 上随改随生效，容器重建也不怕丢。我自己日常折腾 Redis 参数时最喜欢这种模式，改完配置重启容器就能测试，完全不污染 Windows 环境。
4.3 三套方案到底怎么选
经常有朋友问我：既然三种方式都能跑 Redis 7，那到底该选哪种？我给一个相对明确的建议：
| 对比维度 | WSL 2 原版 | Memurai | Docker 容器 |
|---|---|---|---|
| Redis 官方特性还原度 | 100% | 大部分，但模块类功能缺失 | 100%（基于官方镜像） |
| 安装复杂度 | 中等 | 简单 | 中等 |
| 资源占用 | 中等 | 低 | 较高 |
| 多版本切换 | 麻烦 | 不支持 | 非常方便 |
| 开机自启 | 需要配置 systemd | 自带 Windows 服务 | 配置 restart 策略 |
| 适合场景 | 开发、学习、生产模拟 | 轻量开发、桌面应用集成 | 多环境测试、CI 流程 |
如果你追求 Redis 7 新特性完整验证，比如要试 Redis Functions 或 Sharded Pub/Sub，首选 WSL 2 或 Docker。如果你只是想在本地写代码调接口，Memurai 的轻量体验其实更好，能耗也低。如果团队已经有 Docker 化流程，那不用犹豫，直接上容器方案，开发和线上环境保持一致比什么都重要。
5. Redis 7 安装后的验证与日常运维
5.1 用 redis-cli 完成一次冒烟测试
无论是哪条路线，Redis 7 装完之后都要做一遍完整的冒烟测试，确认基础功能和持久化都没问题。除了ping之外，我一般还会执行这几个命令：
redis-cli -a your-strong-password SET test:key hello redis-cli -a your-strong-password GET test:key redis-cli -a your-strong-password TYPE test:key redis-cli -a your-strong-password INFO keyspaceSET 和 GET 验证基本读写，TYPE 验证数据结构存储，INFO keyspace 能看到当前库有多少 key。做完这些后，我会重启一次 Redis 服务，再 GET 一次test:key，确认持久化配置生效。如果重启后 key 消失了，说明appendonly没开，或者数据目录没写权限，这个问题越早发现越好。
另外建议顺手看一眼 Redis 7 的版本特征，确认你用的确实是 7.x 而不是 6.x：
redis-cli -a your-strong-password INFO server输出里的redis_version字段应当是7.x.x。
5.2 把 Redis 7 配置成 Windows 环境下的常驻服务
开发机上的 Redis 经常需要长时间运行，手动启动一个终端窗口实在不够优雅。三种方案各自有对应的常驻方式：
- WSL 2 方案：配置 systemd 托管 redis-server 服务，然后
systemctl enable redis-server实现开机自启。 - 方案二：Memurai 安装时默认注册为 Windows 服务，自带开机自启能力。
- 方案三：Docker 容器配
--restart unless-stopped，再把 Docker Desktop 设置为登录时自动启动。
在实际使用中，我自己的偏好是 WSL 2 加 systemd 的方案，因为它最接近 Linux 服务器的运维习惯，后续上生产环境时迁移成本最低。很多坑也都是在这个环节暴露出来的，比如 systemd 托管 Redis 后，日志默认进 journald，查看日志要用journalctl -u redis-server，而不是直接看文件，这个和手动启动时的行为有差异。
5.3 常用客户端工具与连接配置备忘
服务跑起来之后，日常开发还需要趁手的客户端工具。命令行工具 redis-cli 是标配，但看数据流、检查 key 的过期时间、监控慢日志时，我更喜欢用图形化工具。这类工具很多，选择时注意一点：它们大多不区分后端实现，只要是 Redis 协议就能连，所以 WSL、Memurai、Docker 三套环境下都能用同一款工具。
连接参数其实也就那几个，顺手列一下：
| 配置项 | 示例值 | 说明 |
|---|---|---|
| host | 127.0.0.1 | 本机连接通常用回环地址 |
| port | 6379 | 默认端口，改过配置则以实际为准 |
| password | your-strong-password | 开启 requirepass 后必须填 |
| database | 0 | Redis 默认有 16 个库，编号 0-15 |
还有一个容易被忽略的点：Redis 7 里的 ACL 用户系统比旧版本更完善，密码可以直接在连接 URL 里体现。比如 Python 客户端可以：
import redis r = redis.Redis.from_url("redis://:your-strong-password@127.0.0.1:6379/0") r.set("foo", "bar") print(r.get("foo"))这种连接方式在配置管理里比较常见，也适合写进测试用例。
6. 常见问题与排错实录
6.1 端口被占用与多个 Redis 实例冲突
我在一台机器上同时折腾过 WSL 原版、Memurai 和 Docker 容器，最常遇到的第一大坑就是 6379 端口被占用。现象是 Docker 容器启动时报端口映射失败，或者 Memurai 服务启动后日志提示 bind 失败。排查端口占用用 Windows 自带命令：
netstat -ano | findstr :6379看输出里的 PID，然后去任务管理器里确认对应进程是谁。如果确实是旧 Redis 实例，先停掉旧实例再启动新的。如果想共存，那就需要给不同实例分配不同端口，比如把 Docker 容器映射到 6380：
docker run -d --name redis7 -p 6380:6379 redis:7-alpine这里也顺便提一下 Redis 7 的新功能端口偏移问题。Redis 7 引入了集群总线端口偏移，默认情况下，6379 端口的集群实例会额外占用 16379 这个集群总线端口。虽然单机开发通常不涉及集群，但如果你用了--cluster-enabled yes，端口绑定冲突会发生在两个端口上，排查时要额外留意。
6.2 “NOAUTH Authentication required”和连接被拒
很多人在配置里加了requirepass之后，用 redis-cli 直接执行命令就报NOAUTH Authentication required。这个本质是没走认证流程，执行命令前先认证：
redis-cli -a your-strong-password ping或者进入交互模式后先执行AUTH your-strong-password再操作。但要注意，在命令行直接写密码有一个副作用：进程列表里会短暂暴露密码。如果是在共享机器上操作，建议使用REDISCLI_AUTH环境变量：
set REDISCLI_AUTH=your-strong-password redis-cli ping这个技巧我也是在排查问题时偶然发现的，比直接在命令行里写密码稍微安全一点。
另一个常见的“连接被拒”原因是指纹没对上。Redis 7 默认protected-mode yes，当你把bind从127.0.0.1改成0.0.0.0后，如果没有设置密码，Redis 会拒绝所有外部连接，日志里会出现Denied redis connection for ip ...。破解方法很简单：必须设置密码，或者显式把protected-mode no，但后者在暴露到外网时风险很高，非常不建议。
6.3 WSL 2 里 Redis 启动正常但 Windows 连不上
这种情况我在不同机器上遇到过好几次。WSL 内部的 Redis 服务在 Ubuntu 里怎么测都能通，但 Windows 侧的程序连不上。先说最常见的两个原因：
第一，Redis 在 WSL 里只监听了 IPv6 的回环地址::1，Windows 侧转发逻辑有时对 IPv4 和 IPv6 处理不一致。解决办法是把 redis.conf 里的 bind 改成：
bind 127.0.0.1 -::1确保 IPv4 回环被监听。
第二，WSL 的 localhost 转发偶发失效。这是 WSL 2 的老毛病，一般重启一下 WSL 就好：
wsl --shutdown然后再重新启动 Ubuntu。我印象最深的一次是 Windows 更新后，转发彻底失效，重启也没用。最后是把 WSL 内核更新到最新版才解决。所以如果遇到转发问题，先检查 Windows 更新、WSL 内核版本，再考虑配置问题。
6.4 Redis 7 的日志告警与性能相关提示
Redis 7 启动时偶尔会输出一些 warning 日志，虽然没有直接阻碍运行，但往往指明了潜在的坑。最常见的告警有两个。
第一个是关于内存过账的：
WARNING Memory overcommit must be enabled without it这句的意思是系统内存 overcommit 没开启，fork()持久化时如果内存压力大，有可能导致后台保存失败。在 WSL/Linux 里通过修改内核参数解决：
sudo sysctl vm.overcommit_memory=1如果想要永久生效，写入/etc/sysctl.conf。Docker 容器里跑 Redis 时也可能出现这个告警，但容器对系统内核参数没有修改权限，一般选择忽略，或者保证容器内存上限充足。
第二个是关于 THP（Transparent Huge Pages）的告警：
WARNING you have Transparent Huge Pages (THP) support enabledTHP 开启后，Redis 的 fork 持久化可能出现更严重的延迟，官方建议关闭。在 WSL/Linux 里需要 root 权限操作，但不同发行版关闭方式不太一样。开发环境如果只是偶尔用到，忽略该告警也没有大问题。这两个告警在 Memurai 上不会出现，因为它是原生 Windows 服务，不走 Linux 内核路径。
最后再分享一个细节：Redis 7 的默认日志级别是notice，日志输出到 stdout。用 systemd 托管后日志会进 journald，看日志的命令是：
journalctl -u redis-server -n 50 --no-pager排查问题时，日志永远是最好的第一位线索，不要一上来就怀疑配置和网络，先把日志拉出来看一遍，很多问题都有明确记录。
7. 安全加固与性能基础调优
7.1 Redis 7 的 ACL 权限模型基础操作
Redis 7 在权限控制上的升级力度很大，除了传统的requirepass，更推荐用 ACL 来按用户分配权限。对开发环境而言，建一个只读用户和一个读写用户能避免不少误操作。ACL 基本操作在 redis-cli 里直接执行：
ACL SETUSER readonly on >readonly-pass ~* +@read ACL SETUSER dev on >dev-pass ~* +@all第一条命令创建了readonly用户，只能执行@read类命令，比如 GET、LRANGE、HGETALL；第二条创建了dev用户，拥有全部命令权限。配置写入后，把 redis.conf 里的requirepass保留作为默认用户的密码，同时通过user指令固化 ACL：
user readonly on >readonly-pass ~* +@read user dev on >dev-pass ~* +@all实际项目里，我见过太多图省事只用requirepass然后所有客户端共享一个密码的情况。如果 Redis 7 能按环境拆分用户，排查问题时能从连接信息里直接看出是哪个业务在读写，并且撤销某个客户端的权限也只需要ACL DELUSER一条命令，不用改全局密码影响所有人。
7.2 内存限制与过期策略的合理配置
Redis 本质是内存型数据库，内存管理是日常运维里绕不开的话题。Redis 7 默认 64 位系统下不设置 maxmemory，也就是说它能一直吃内存直到系统资源耗尽，这在实际运行中是很危险的。开发机上我一般会这么设置：
maxmemory 1gb maxmemory-policy allkeys-lrumaxmemory-policy allkeys-lru的意思是当内存到达上限时，按最近最少使用策略淘汰 key。如果业务中存在大量固定缓存且不能淘汰，就把策略改成volatile-lru，只淘汰设置了过期时间的 key。这里的关键点是：Redis 7 提供的内存分析工具也值得一试，比如MEMORY USAGE命令能精确查某个 key 占了多少字节：
redis-cli -a your-strong-password MEMORY USAGE test:key我在排查 Redis 内存异常增长时，用这个命令快速定位过大 key，比如几 MB 的字符串、几十万成员的哈希表，一眼就能看出问题。
7.3 网络暴露面与防火墙的基本常识
无论你最终选择哪套方案，只要 Redis 监听地址不是127.0.0.1，就要面对网络暴露的风险。Redis 本身没有内置 TLS 支持（Redis 7 的企业版和部分模块才支持），生产环境如果必须走网络，至少要做到三点：设置强密码、使用 ACL 最小化权限、只监听必要的 IP 而不是0.0.0.0。
Windows 防火墙上，我一般会单独建一条入站规则，只允许内网网段的 IP 访问 6379 端口，而不是直接放行所有来源。这个在 Docker 和 Memurai 方案里都适用。WSL 2 方案的防火墙规则相对特殊，因为 WSL 使用虚拟网卡，同一个 Windows 防火墙规则可能不生效，所以更建议监听回环地址或者只对 Windows 本地服务开放。
对个人开发机来说，最简单的安全策略其实是：不要让 Redis 监听非回环地址。如果只有本机程序要连，127.0.0.1就足够，连防火墙都不用开。
8. 我在实际使用中的几点偏好和教训
折腾 Redis 7 for Windows 这件事前前后后花了我不少时间，三种方案我都真正在实际项目里跑过，说几个个人体会比较深的地方。
如果只是写代码调接口，我现在倾向先用 Memurai 或者 Docker，因为它们对 Windows 开发环境最友好、开关干净，装了不想要了卸载也方便。但如果是准备在 Linux 服务器上部署的项目，我在 Windows 上一定会用 WSL 2 跑原版 Redis，而且是同一个大版本、同样的配置文件和启动参数，这样从开发到生产的迁移几乎无缝。
另外有个小技巧想分享：WSL 2 里跑 Redis，如果频繁开关 Windows 睡眠和唤醒，有时 redis-cli ping 会反应迟缓。这不是 Redis 本身慢，而是 WSL 虚拟机在宿主机睡眠后网络栈没有立即恢复。遇到这种情况别急着重启 Redis，先在 Windows 终端里跑一下wsl --shutdown，再进 WSL 重启 redis-server，基本就恢复正常了。这个经验我在三台不同配置的机器上都复现过。
最后，无论用哪条路线，装好后建议花 10 分钟做一遍完整的冒烟测试：读写、过期、持久化、重启恢复、ACL 权限验证，都过一遍。这样后面写代码联调时，所有问题都只会出现在业务逻辑层面，而不会冒出环境问题来干扰判断。
