企业官网建设流程全解析

本地调试要用 Redis，结果打开官网发现下载页只有 Linux 和 macOS 的源码包，Windows 一栏空着——这个场景我猜你正在经历，因为"Windows 安装 Redis"本身就是个官方没打算让你顺利完成的动作。Redis 从诞生起就是为类 Unix 系统写的，官方长期只提供源码和 Linux 发行版包，Windows 用户拿到的所有"安装包"，本质上都是别人移植、编译、打包过的产物。这就带来一个连锁问题：不同来源的包，版本号不一样，命令支持不一样，配置文件写法不一样，甚至装完之后跑不跑得起来，取决于你把压缩包解压到了哪个盘、哪个目录、路径里有没有空格。这篇文章把 Windows 装 Redis 这件事拆成一条完整链路——从选哪个版本、怎么落地、怎么注册成服务开机自启，到连不上时怎么一步步定位，再到缓存策略、备份迁移和最后的清理卸载。不管你是刚接触 Redis 的新手，还是习惯了在服务器上操作、回到 Windows 桌面环境就有点别扭的老手，都能照着走一遍。

1. Windows 版 Redis 的来龙去脉：先搞清楚你装的是什么

1.1 官方为什么长期不给 Windows 出安装包

要理解 Windows 上装 Redis 为什么这么别扭，得先看 Redis 的内部实现。Redis 的持久化机制里有一环叫fork：当它要执行 RDB 快照落盘时，会 fork 出一个子进程，让子进程去写磁盘，主进程继续处理请求。这个设计和 Linux 的写时复制（Copy-On-Write）内存模型配合得非常好，代价极低。而 Windows 的进程模型里根本没有等价的 fork 语义，强行模拟要付出巨大的复杂度和性能代价。

除此之外，Redis 单线程事件循环依赖的是 epoll / kqueue 这类高并发 IO 多路复用接口，Windows 对应的是 IOCP，两者编程模型差异很大。再加上内存分配器（Linux 上常用 jemalloc）、文件系统的 fsync 行为、进程信号机制全都不一样，官方判断投入产出比不划算，于是干脆把 Windows 支持交给了社区。所以你在网上看到的所有 Windows 版 Redis，没有一个是 Redis 官方发布的，这一点必须先在心里立住，后面所有的坑都源于此。

1.2 现在能在 Windows 上跑的几种 Redis 分别是什么来头

目前桌面和 Windows Server 环境下能落地的方案，大致可以归为四类，每一类的"血统"和脾气都不一样：

这四类的差别不是"好不好用"，而是"你拿它干什么"。本地写代码时验证一下缓存逻辑，微软归档版够了；如果你要本地跑一个带 Stream 消息队列的 demo，那 3.0 会直接报未知命令；如果你要模拟线上的主从、哨兵甚至集群，那就别在 Windows 原生版上折腾了，直接上 WSL2 或容器。

1.3 一个残酷但有用的事实：版本号决定你能用什么命令

很多人装完 Redis 之后，第一反应是照着某篇博客敲命令，然后发现敲一个报一个unknown command。原因是那篇博客用的是新版 Redis，而你装的是 3.0 或 3.2。这里列几个关键的版本分界线，装之前先对一下自己的需求：

• GEO 地理位置命令（GEOADD、GEODIST）从 3.2 开始才有，3.0 版本敲了必报错；
• Stream 消息队列（XADD、XREAD、XACK）从 5.0 开始支持，3.x 全系没有；
• UNLINK 异步删除、MEMORY USAGE 内存统计从 4.0 起才有；
• ACL 权限体系（多用户、细粒度权限）从 6.0 起才有，之前只有单一requirepass；
• 多线程 IO、Function 脚本这些是 6.0 到 7.0 逐步引入的，Windows 原生版基本碰不到。

我个人的判断标准很粗暴：如果你的项目代码里用到了 Stream，或者客户端 SDK 依赖了较新的命令，直接跳过原生版，走 WSL2 或容器。别为了"装得快"把自己堵在版本墙上，后面改起来更麻烦。

2. 四条落地路线怎么选：别上来就下载压缩包

2.1 四条路线的横向对照

选路线的时候，我一般会问三个问题：这台机器是长期用的开发机还是临时验证的虚拟机？我要不要它开机自启？我要的 Redis 版本是多少？把这三个问题套进下面的对照表，基本就能定下来。

看完这张表你会发现一件事：原生解压版唯一不可替代的优势就是"快"，两分钟就能跑起来，用完删掉不留痕。而一旦你需要"开机就有"、"版本要新"、"要模拟多节点"，原生版的短板就全暴露了。

2.2 临时验证就选原生解压版，但心里要清楚它的边界

什么时候用解压版最合适？你在看一份 Redis 数据类型教程，想边看边敲；你在排查一个缓存穿透问题，想本地复现一下；你在给同事做一次内部技术分享，需要一个五分钟能起来的演示环境。这些场景下，解压版的"零安装、零注册表、零服务"反而是优点。但你必须接受它的两个限制：一是关掉命令行窗口 Redis 就停了，二是版本被锁死在移植版那个年代。

我见过不少人拿解压版当长期开发环境用，然后每次重启电脑都要手动双击一次启动脚本，最后干脆写个 bat 塞进启动目录——到这一步其实已经该换成服务版了，只是很多人没意识到有更省事的做法。

2.3 需要长期驻留就注册服务，需要环境一致就上虚拟层

判断标准很简单：如果这个 Redis 需要在你不登录的情况下也能被其他程序访问，就应该注册成 Windows 服务。服务模式下 Redis 由系统服务管理器托管，开机自动拉起来，不会因为你关了终端窗口就断掉，日志也有固定位置可查。

而如果你的目标是"本地环境和线上环境行为一致"，那答案基本只有一个：WSL2 或者 Docker。因为线上跑的是 Linux 版 Redis，持久化用的是 fork，内存分配器是 jemalloc，这些差异在你本地可能一辈子遇不到，但一旦遇到就是"本地好好的、线上莫名其妙"的诡异问题。花半小时配好 WSL2，能省掉后面无数次的自我怀疑。

3. 原生解压版实战：从下载到 PONG 的完整链路

3.1 下载与解压：路径里别出现中文和空格

先去拿包。微软归档的移植版发布在代码托管平台上，搜项目名就能找到 Release 页面，附件里是 zip 包；社区编译版同理。下载的时候认准 zip，不要下 tar.gz，Windows 上解压 tar.gz 容易出编码和换行符问题。

解压路径是第一个大坑。我踩过的真实故障是这样的：把 Redis 解压到了D:\我的资料\开发工具\redis 5.0\，启动瞬间报错退出，日志里一行乱码都看不清。原因有两个：路径里有中文，路径里有空格。Redis 的 Windows 移植版在处理命令行参数和配置文件里的路径时，对非 ASCII 字符和不带引号的空格支持很差，配置项里写相对路径更是直接翻车。

所以规矩定死：解压到纯英文、无空格、层级尽量浅的目录，比如D:\redis或者C:\tools\redis。这个习惯值得保持，后面配置日志文件、数据目录的时候你还会感谢自己。

3.2 目录里每个文件是干什么的

解压完打开文件夹，如果你第一次见会有点懵，一屏都是 exe。把用途记住，排错时能省很多时间：

• redis-server.exe：服务端主程序，Redis 本体，所有启动方式最终都是在调它；
• redis-cli.exe：命令行客户端，你后面敲 SET、GET 用的就是它；
• redis-benchmark.exe：内置压测工具，想知道你这台机器能扛多少 QPS 靠它；
• redis-check-aof.exe：AOF 文件损坏时的修复工具；
• redis-check-rdb.exe（老版本叫 redis-check-dump.exe）：RDB 文件检查工具；
• redis.windows.conf：给命令行前台启动用的配置文件；
• redis.windows-service.conf：给注册成系统服务用的配置文件，两者内容基本一致但默认参数不同。

重点说说最后两个配置文件。为什么要有两份？因为服务模式和前台模式对日志、持久化路径的默认要求不一样。服务是以系统身份在后台跑的，工作目录不确定，如果配置文件里用相对路径写日志和数据文件，很可能被写到C:\Windows\System32下面去，既找不到又不好清理。所以服务版配置文件里的logfile和dir建议一开始就改成绝对路径。

3.3 第一次启动与三种验证方式

前台启动最简单，在 Redis 目录里开一个命令行窗口，执行：

redis-server.exe redis.windows.conf

回车之后如果看到一个大大的 Redis ASCII 图，底下跟着端口信息和服务就绪提示，说明起来了。这个窗口千万别关，关了服务就停。想验证它是否真的在工作，有三种方式，从轻到重：

第一种，再开一个窗口，进到同一目录，敲redis-cli.exe进交互模式，然后输入：

127.0.0.1:6379> PING PONG

返回PONG就通了。第二种，不改配置文件直接命令行传参验证端口和密码：

redis-cli.exe -h 127.0.0.1 -p 6379 -a 你的密码 PING

第三种，看服务端窗口有没有新连接日志，或者用INFO server看版本号和运行时长。我一般推荐先用第一种确认链路通，再用INFO确认版本号，因为后面能不能用某个命令，全看这个版本号。

3.4 用五种数据类型做一次"验货"

PING 通了只能说明进程活着，不代表功能完整。花两分钟把数据类型过一遍，能顺带确认配置里的maxmemory、持久化之类有没有把写入挡住：

# 字符串 SET user:1001:name "张三" GET user:1001:name # 哈希，适合存对象 HSET user:1001 age 28 city "杭州" HGETALL user:1001 # 列表，可以做简单的消息队列 LPUSH queue:tasks task1 task2 LRANGE queue:tasks 0 -1 # 集合，适合去重统计 SADD article:9:likes u1 u2 u3 SCARD article:9:likes # 有序集合，适合排行榜 ZADD rank:score 95 u1 88 u2 76 u3 ZREVRANGE rank:score 0 -1 WITHSCORES

顺手再加一句EXPIRE user:1001:name 60和TTL user:1001:name，验证过期策略是否生效。这里有个容易被忽略的细节：Windows 命令行默认编码是 GBK，写中文进去再读出来可能是乱码。解决方式是在敲命令前执行chcp 65001切到 UTF-8，或者干脆用支持 UTF-8 的终端（比如 Windows Terminal）操作。这个乱码问题不影响数据本身，只影响你看到的显示，但排查的时候很容易被它带偏。

4. 注册成 Windows 服务：让 Redis 开机自启且不随窗口关闭

4.1 服务安装命令与参数含义

服务模式的核心就三条命令，记住它们基本就够了。安装服务：

redis-server.exe --service-install redis.windows-service.conf --loglevel verbose

启动、停止、卸载分别是：

redis-server.exe --service-start redis-server.exe --service-stop redis-server.exe --service-uninstall

这里有个细节值得说清楚：--service-install后面的配置文件路径，最好写绝对路径，而且在 Windows 上反斜杠需要转义或者改用正斜杠。我一般写成D:/redis/redis.windows-service.conf这种形式，省心。另外--loglevel verbose是安装过程的输出级别，装失败的时候它会告诉你到底哪一步不行，比默认的静默失败有用得多。

还有一个最容易忽略的点：安装服务时当前目录会影响服务的工作目录。建议先在 Redis 目录里用管理员权限打开命令行，再执行安装命令。安装完成后用services.msc或者sc query Redis能看到名为 Redis 的服务项。

4.2 配置文件里必须改的六个参数

默认配置文件是"能跑但不安全"的，直接上服务之前建议把这六个参数过一遍：

• bind：默认可能是127.0.0.1，这是好事，只允许本机访问。如果确实需要局域网访问，改成具体的内网 IP，不要图省事写0.0.0.0，那等于把 Redis 暴露给所有能连到你机器的人；
• port：默认 6379，多实例时需要改；
• requirepass：这是本地开发机最容易被跳过的一项。哪怕只在本机跑，只要这台机器接入了办公网，没有密码的 Redis 就是一个敞开的门。设一个足够长的随机串，写进配置，客户端连接时用-a带上；
• maxmemory：Windows 版尤其要设，原因见 4.4 和 6.4；
• maxmemory-policy：配合上面一项，决定内存满了之后淘汰谁，常用allkeys-lru或volatile-lru；
• logfile和dir：改成绝对路径，例如D:/redis/log/redis.log和D:/redis/data，注意这两个目录要先建好。

配置文件的编码也有讲究：必须是 UTF-8 且不带 BOM。用记事本另存为的时候如果选了"UTF-8 带 BOM"，服务启动会直接失败，日志里还看不出明显原因，这个坑我踩过一次，排查了半小时。

4.3 多实例共存：在一台机器上跑 6379 和 6380

本地要模拟主从或者做隔离测试，经常需要在一台机器上跑两个 Redis。做法是复制一份配置文件改成 6380 端口，然后带服务名安装：

redis-server.exe --service-install redis-6380.conf --service-name redis6380 --loglevel verbose redis-server.exe --service-start --service-name redis6380

几个必须同步改的地方：port改成 6380；logfile和dir必须和 6379 实例分开，不然两个实例会抢同一个 RDB 文件；pidfile如果配置里有也要区分。管理多实例时，--service-name这个参数不能漏，否则命令会作用到默认名字的服务上，出现"我明明停的是 6380，结果 6379 停了"这种乌龙。检查实例状态可以用sc query redis6380，或者直接redis-cli -p 6380 PING。

4.4 服务启动失败时的日志定位法

服务装上了但起不来，是 Windows 环境下最常见的场景。别急着反复重装，按这个顺序查：

第一步，看服务状态和错误码。命令行执行sc query Redis，如果是STOPPED且启动时报了具体错误码，先记下来。第二步，去配置的logfile路径找日志，如果日志文件根本没生成，说明失败发生在日志初始化之前，问题多半在配置文件的编码或路径上。第三步，如果日志文件生成了但内容奇怪，重点看有没有 "Can't open the log file"、"Invalid argument during startup" 这类信息。第四步，如果日志显示端口绑定失败，那就是 6379 被别的程序占了，处理方式见 6.1。

还有一种情况：服务状态是"正在启动"然后自动变成停止，日志里什么都没有。这种大概率是配置文件路径写错或者权限不足——服务以 LocalSystem 身份运行，如果 Redis 目录放在了某个普通用户的家目录下且没给系统账户读权限，它会读不到配置。解决办法是把 Redis 放在公共目录，或者给目录加上系统账户的读取权限。

5. 容器与 WSL2 路线：更贴近线上环境的两套做法

5.1 Docker Desktop 跑 Redis 的最小命令与持久化

如果机器上已经有 Docker Desktop，拉起一个 Redis 只需要一行：

docker run -d --name redis-local -p 6379:6379 -v redis-data:/data redis:7.2 redis-server --appendonly yes

拆开看每个参数：-d后台运行；--name给容器起名方便管理；-p 6379:6379把容器端口映射到本机，前半是宿主机端口，后半是容器端口，冲突时改前半段；-v redis-data:/data把数据目录挂到具名卷上，容器删了数据还在；最后的redis-server --appendonly yes是覆盖容器默认启动命令，开启 AOF 持久化。

想验证，直接进容器敲命令：

docker exec -it redis-local redis-cli PING

有一个坑要提前说：Docker Desktop 在 Windows 上的端口映射是通过端口代理实现的，本机其他程序连 127.0.0.1:6379 一般没问题，但在某些网络配置下会用 IPv6 的::1解析，导致连不上。遇到这种情况，客户端里明确写127.0.0.1而不是localhost，多数时候就能解决。

5.2 docker-compose 版本：主从与密码一次配好

如果你需要演练主从复制，用 compose 比手敲 run 命令清爽得多：

services: redis-master: image: redis:7.2 container_name: redis-master ports: - "6379:6379" command: redis-server --requirepass devpass123 --appendonly yes volumes: - ./master-data:/data redis-replica: image: redis:7.2 container_name: redis-replica ports: - "6380:6379" command: redis-server --requirepass devpass123 --masterauth devpass123 --replicaof redis-master 6379 depends_on: - redis-master volumes: - ./replica-data:/data

注意--masterauth和--replicaof这两个参数：主节点设了密码，从节点复制时必须带masterauth，否则你会看到从节点一直重连但同步不成功。启动后用docker compose up -d，然后redis-cli -p 6380 -a devpass123 INFO replication看role:slave和master_link_status:up，两个都对了才算主从通了。演练完docker compose down，环境干净得像没来过。

5.3 WSL2 里装 Redis 的两种启动方式

WSL2 路线的本质是：你在一台 Windows 电脑里跑了一个轻量 Linux 虚拟机，然后在里面用官方源装 Redis。进入发行版之后：

sudo apt update sudo apt install redis-server -y

装完之后有两种启动方式。老式的做法是直接敲redis-server（前台）或者sudo service redis-server start，简单但不够"系统化"。更贴近线上的是开启 systemd 后用 systemctl 管理：在/etc/wsl.conf里加上[boot]段的systemd=true，然后wsl --shutdown重进一次，之后就能用：

sudo systemctl start redis-server sudo systemctl enable redis-server sudo systemctl status redis-server

这样 Redis 就跟着 WSL 实例一起开机自启了。关键问题是 Windows 侧怎么连进去：WSL2 有自己独立的网络空间，但微软做了本地回环转发，所以在 Windows 的客户端里连127.0.0.1:6379通常能直接通。如果连不上，先在 WSL 里redis-cli PING确认服务本身没问题，再检查发行版里的bind配置——默认配置可能只绑定了127.0.0.1，在 WSL 内部是够的，如果要做端口转发则需要额外调整（这属于进阶用法，本地开发一般用不到）。

6. 连不上的时候：Windows 下最高频的报错逐个拆

6.1 端口占用与 bind 失败的排查链路

报错长这样的时候，你八成遇到了端口冲突：Creating Server TCP listening socket *:6379: bind: No error。这个提示的措辞非常误导人，它说 "No error"，实际意思是"绑定失败了，但系统没给出更详细的原因"，最常见的原因就是端口已被占用。

排查链路固定两步。第一步找占用者：

netstat -ano | findstr :6379

输出最后一列是进程 PID。第二步用 PID 反查是谁：

tasklist | findstr 换成上一步的PID

结果可能是另一个 Redis 实例、某个客户端工具自带的内嵌服务，甚至是某个你早就忘了的测试程序。确认之后，要么结束那个进程，要么给 Redis 换个端口。顺带提醒一句：netstat看到0.0.0.0:6379是"所有网卡都在监听"，看到127.0.0.1:6379是"只有本机能连"，这两个状态的含义差别很大，看的时候别混。

6.2 NOAUTH 与 protected mode 的触发条件

NOAUTH Authentication required的意思很直接：服务端设了密码，你没带。用redis-cli -a 密码重连，或者进了交互模式后执行AUTH 密码。这里有个小坑要注意：较新版本的客户端会警告"命令行传密码不安全"，这只是提示，不影响使用，本地开发不用纠结。如果是在代码里连，密码要写在连接配置里，别硬编码在源码中。

DENIED Redis is running in protected mode是另一种情况。当 Redis 处于保护模式，并且收到了来自非本机地址的连接时，会直接拒绝。触发条件是：没有设置密码，同时bind配置没有明确限制，且配置里protected-mode是开启的。三种解法：加密码、明确bind 127.0.0.1、或者显式关掉保护模式（不推荐第三种）。我强烈建议选前两种，尤其是本地机器接了公司网络的情况，加个密码的成本几乎为零。

6.3 配置文件编码、路径与参数的坑

前面零散提过，这里集中列一下，因为这类问题的共同特征是"启动失败但报错看不懂"：

最后一行特别值得说：命令行前台启动读的是redis.windows.conf，服务模式读的是安装时指定的那份配置文件。很多人改了 A 文件，重启服务看的是 B 文件，然后死活找不到问题在哪。排错时先把"当前生效的配置文件到底是哪个"确认清楚，能省掉一半时间。

6.4 内存相关的报错与 Windows 的 maxheap

Windows 移植版引入了一组 Linux 版没有的参数，用来管理一个基于内存映射文件实现的堆，典型的是限制堆大小的参数和指定堆文件目录的参数。这套机制存在的意义是绕开 Windows 在内存分配行为上和 Linux 的差异。如果你遇到了类似"内存分配失败"或者服务用着用着被系统杀掉的情况，可以从这几个方向处理：

先给maxmemory设一个明确的值，比如 256MB 或 512MB，再配上淘汰策略，别让进程无限膨胀；然后确认数据目录所在磁盘有足够空余空间，因为堆文件和 RDB、AOF 文件都要落在磁盘上；最后检查dir指向的磁盘类型，放在机械盘上做高频写入会很吃力。还有一点：这种移植版的内存回收效率不如 Linux 原生版，长时间高频写入之后内存占用可能降不下来，这种情况重启服务比任何调参都有效，也正因如此，Windows 原生版不适合跑对内存敏感的长期服务。

7. 图形客户端与日常运维：连接、监控、内存治理

7.1 主流可视化管理工具怎么选

命令行敲多了总会想要一个能点着看的地方。常见的几类工具各有侧重：

• RedisInsight：官方出的图形工具，功能最全，能看内存分析、慢查询、可视化命令构建，缺点是体积大、启动稍慢；
• Another Redis Desktop Manager：轻量、开源、启动快，日常看键值、翻列表、改字符串完全够用，我本地最常用的就是它；
• 各类数据库客户端内置的 Redis 模块：如果你本来就在用某个集成式数据库管理工具，很多都自带 Redis 连接支持，好处是省一个软件，坏处是功能相对基础。

连接时的常见问题是工具能连但看不到数据，或者看到的是空库。九成是因为选错了数据库索引——Redis 默认有 16 个库（编号 0 到 15），很多工具默认连 0 号库，而你的程序写的是 1 号库。命令行客户端里可以用SELECT 1切库，工具里一般在连接配置或界面顶部有库号选择器。这个"数据去哪儿了"的问题，我在团队里见过太多次，先把库号对一遍再怀疑别的。

7.2 用 INFO 和 SLOWLOG 做一次体检

装完跑起来之后，值得养成看一眼运行时状态的习惯。INFO命令会输出一大段统计信息，我一般重点看几项：

• used_memory_human：已用内存，配合maxmemory看还有多少余量；
• connected_clients：当前连接数，如果数值持续上涨不回落，可能有连接泄漏；
• keyspace_hits和keyspace_misses：命中率，两个数一除就知道缓存有没有白做；
• total_commands_processed：累计命令数，和运行时长一起看能估算大致吞吐；
• role：当前实例是主还是从，做复制演练时必看。

SLOWLOG GET 10能列出最近的慢命令，默认阈值是 10 毫秒。本地开发机如果出现大量慢命令，通常不是 Redis 慢，而是你敲了KEYS *这种全量扫描命令。生产环境严禁使用KEYS，本地也建议换成SCAN游标迭代：

SCAN 0 MATCH user:* COUNT 100

它的好处是一次只返回一小批，不会因为键太多把服务卡住。养成用SCAN的习惯，将来把代码搬到线上时不用改写法。

7.3 缓存治理：maxmemory-policy 怎么定

内存满了怎么办，这是缓存治理的核心问题，答案取决于你的数据用途。把策略定成下面几种之一：

选法有个简单判断：如果这个 Redis 实例里的数据全都能从数据库重建，选allkeys-lru；如果里面混了不能丢的数据，选volatile-lru，并且把可丢的数据都设上过期时间。混用的情况最危险，很多线上事故就是因为一次内存打满，把不该淘汰的数据顺手清了。本地开发时也建议按这个规则配，别用默认值糊弄过去，习惯是一点点养成的。

比较特殊的是LRU在 Redis 里的实现并不是严格的最近最少使用，而是采样近似。也就是说淘汰的对象有一定随机性，只是大概率命中"不常用"的那批。理解这一点，你就不会奇怪为什么某个刚设的键也被清掉了——它的采样运气不好。真正需要严格淘汰控制时，得从业务层做更精细的键设计和容量规划。

7.4 数据备份与迁移

Windows 上做备份，最简单的办法是利用 RDB 文件。在客户端执行BGSAVE触发后台保存，然后去dir配置指向的目录里找dump.rdb，这个文件就是某一时刻的完整数据快照。把它拷走就等于完成了一次冷备。需要注意的是：

• Windows 移植版的后台保存行为和 Linux 不完全一样，因为缺少 fork，它在保存期间可能对主线程有短暂影响，本地无所谓，但如果你在跑压测，别同时触发保存；
• 拷贝dump.rdb之前先SHUTDOWN SAVE让服务把数据落盘并退出，避免拷到写了一半的文件；
• 把 RDB 恢复到另一个实例时，文件名必须是dump.rdb，放在目标实例的dir目录下，启动时会自动加载。

数据量小的时候，也可以用redis-cli --rdb把快照直接导出到本地文件。更精细的场景下，用命令逐键导出成文本然后重放也是可行的，只是效率低。唯一不建议的做法是直接拷 AOF 文件跨环境迁移，因为 AOF 依赖原始的命令序列和版本兼容性，版本不一致时加载失败的概率很高。

8. 卸载与收尾：把服务、端口、残留文件清干净

8.1 服务卸载与进程确认

想彻底移除，顺序很重要，先卸服务再删目录。如果直接删文件而服务还在，服务会变成"指向不存在的可执行文件"的状态，每次开机系统都会尝试拉起失败一次，看着不致命但很烦人。

正确流程是：

redis-server.exe --service-stop redis-server.exe --service-uninstall

多实例的情况下，每条命令都要带上对应的--service-name。卸完之后用sc query 服务名确认状态，如果提示服务不存在，说明卸干净了。如果这一步报"服务已标记为删除"之类的信息，通常是因为还有进程占用，去任务管理器结束对应的redis-server.exe进程再试一次。最后用 6.1 里的netstat命令确认 6379 端口已经没人监听。

8.2 数据文件与残留清理

服务卸掉之后，剩下的就是文件。需要清理的位置包括：Redis 解压目录本身；配置文件里dir指明的数据目录（dump.rdb、appendonly.aof以及追加文件都在这里）；logfile指明的日志文件。如果当初偷懒用了相对路径，数据文件可能落在C:\Windows\System32或者你启动命令时的当前目录里，这两个地方都值得搜一下dump.rdb这个名字。

另外有一点值得单独提醒：不要手动去注册表里翻 Redis 相关的键删。正常的--service-uninstall已经把服务注册信息清掉了，剩下个别遗留键通常无害。手动删注册表的风险远大于收益，得不偿失。同理，如果用的是容器或 WSL2，清理方式是docker rm -f 容器名配合docker volume rm 卷名，以及在 WSL 里sudo apt purge redis-server，路径完全不同，别混着操作。

8.3 什么时候该彻底放弃 Windows 原生版

用了几年之后我的结论是：Windows 原生版适合"临时验证"，不适合"长期依赖"。出现下面任何一种情况，我都建议直接切到 WSL2 或容器，别在原生版上继续加配置：

• 你需要 5.0 以上的命令，尤其是 Stream 相关的；
• 你需要演练主从、哨兵这类多节点结构；
• 你的程序在本地通过了但到了线上行为不一致，怀疑和存储、过期、内存回收有关；
• 你的机器内存不大，Redis 用久了越来越占内存且降不下来；
• 你需要一份能直接搬去线上服务器的配置文件。

这几种情况强行在原生版上解决，花的时间足够你把 WSL2 装三遍。而如果你只是想临时起一个 Redis 敲几条命令、看几个数据类型的表现，那原生解压版依然是最省事的选择——下载、解压、双击、PING，两分钟的事。我自己的机器上现在就是这么分工的：临时演示用解压版，跑得干干净净；需要长期开着的开发用实例注册成服务；要验证和线上一致的行为，一律走 WSL2 里的官方版。选对路线之后，"Windows 能不能装 Redis"这个问题就不再是问题了。