真要在 Win10 上把 Redis 跑起来，十个人里有八个会卡在最后一步：服务注册完了，点启动，弹一句"本地计算机上的 Redis 服务启动后停止，某些服务在未由其他服务或程序使用时将自动停止"。这个报错本身没告诉你任何有用信息，日志里那行关键提示才是真正的线索。这篇就把 win10 环境下 Redis 的安装配置从头到尾走一遍，重点放在 Redis 服务无法启动的排查思路上——不是给你一句"重装试试"，而是把每一种失败的可能路径都摊开讲清楚，包括报错怎么读、端口怎么查、配置文件里哪个参数最容易埋雷。适合刚上手缓存中间件的后端开发、需要本地环境做接口调试的同学，也适合被服务启动问题折磨过想找根因的人。

1. 为什么在 Win10 上折腾 Redis：场景与方案选型

1.1 本地跑 Redis 的真实使用场景

很多人是被动装 Redis 的：接手一个老项目，配置文件里写着spring.redis.host=127.0.0.1，跑起来就报连接拒绝，于是开始在本机找 Redis。这是最典型的场景，也是最容易踩坑的场景——因为你只想要"能连上"，却撞上了一整套服务注册、配置路径、权限的坑。

除了被动安装，本地 Redis 还有几类很实在的用途。第一类是学习数据类型，Redis 的 String、List、Hash、Set、ZSet 加上 Bitmap、HyperLogLog、Stream，光看文档没用，敲一遍命令才会有感觉。第二类是本地缓存加速，开发阶段不想每次都打远程测试库，把热点数据塞进本机 Redis，接口响应能快一个数量级。第三类是接口限流与计数器，比如登录失败次数限制、短链访问量统计，这类需求用 Redis 的原子自增实现最省事。第四类是消息队列与延时任务的演示，List 做简单队列、ZSet 做延时队列，够小团队用很久。第五类是单元测试，跑集成测试时用本地 Redis 而不是共享环境，避免互相污染数据。

判断自己属于哪一类，会直接影响后面的配置策略。如果只是本地学习，bind 127.0.0.1加个密码就够了；如果需要给局域网里的同事连，就得处理绑定地址和防火墙；如果要做压测，maxmemory和持久化策略就得提前规划。

1.2 Windows 版 Redis 的三种装法对比

Windows 不是 Redis 的原生主场，Redis 官方只在 Linux 系上做长期维护，所以 Windows 上能跑起来的方案本质上都是"移植"或者"套壳"。主流就三条路，各有各的代价。

这里有个经验判断：如果你只是想解决"项目连不上 Redis"，选第一种，五分钟能搞定；如果你想在本地复现生产环境和行为差异，选第二种；如果你本来就装了 Docker，那第三种几乎没有额外成本。三种方案里，出问题概率最高的是第一种，因为服务注册这一步牵扯到 Windows 服务管理器，而服务管理器的报错信息出了名的含糊。这也正是本文重点要拆的部分。

1.3 版本号怎么挑，以及一个容易忽略的细节

Windows 移植版的版本号看两个地方：主版本和编译日期。主版本决定了支持的命令集，编译日期决定了修补了哪些旧问题。选的时候优先选Redis-x64-5.0.14.1这一类带 x64 标识、日期较新的包，不要去用那种来路不明的、名字里带一堆后缀的压缩包。

还有一个特别容易被忽略的细节：Windows 移植版分redis.windows.conf和redis.windows-service.conf两个配置文件。前者是命令行手动启动时用的，后者是注册成 Windows 服务后读取的模板。很多人注册服务时用了默认参数，服务读的是内置默认值，结果自己改的redis.windows.conf完全没生效，改了半天配置发现没反应，就是因为这个。我的做法是：只保留一份配置文件，注册服务时用完整路径明确指定，彻底杜绝这个歧义。

2. 安装前的环境准备与目录规划

2.1 系统层面要先确认的三件事

第一，确认系统是 64 位。这个不用去翻系统属性，命令行敲一下就清楚：

wmic os get osarchitecture

输出64-bit就没问题。32 位系统跑不了新版移植包，虽然还有老版本能用，但没有折腾的必要。

第二，确认管理员权限可用。注册 Windows 服务必须提权，普通用户执行--service-install会直接失败。建议的做法是：以管理员身份打开一次命令提示符或者 PowerShell，后续所有涉及服务操作的命令都在这个窗口里执行，别用一会儿开一会儿关。

第三，处理系统杀毒软件的扫描干扰。这一点我必须强调，因为它是我遇到过最隐蔽的一类"服务启动失败"。杀毒软件在服务注册瞬间会扫描可执行文件，扫描期间文件被占用，服务管理器拿不到句柄，启动就失败了，而且日志里什么都不写。正确的处理方式不是把防护全关掉，而是把 Redis 所在目录加入排除项（白名单），让它跳过实时扫描。这样既解决了问题，也不影响整机防护。

还有一个细节：确认安装路径里没有中文、没有空格。C:\Program Files\Redis这种路径带空格，在某些版本的移植包里会导致服务启动时的参数解析出错；D:\我的工具\redis这种带中文的路径，出问题的概率更高。老老实实用D:\Redis最省心。

2.2 目录结构规划：别把文件全堆在一个文件夹里

很多人解压完直接把 data 文件、日志、配置、可执行文件全扔在一个目录，跑一段时间后目录里几十个文件，想找个日志都费劲。我建议一开始就把结构分好：

D:\Redis\ ├── bin\ # redis-server.exe、redis-cli.exe、redis-benchmark.exe ├── conf\ # redis.windows.conf ├── data\ # dump.rdb、appendonly.aof └── log\ # redis.log

这么分有三个实际好处。一是备份和迁移简单，只要拷贝 conf 和 data 两个目录就完成了迁移。二是权限控制清晰，如果后面需要给不同账号分配不同目录权限，粒度可控。三是排查问题时不会混淆——日志在 log 里，数据在 data 里，看目录名就知道去哪个文件夹找。

需要提醒的是，data目录必须提前建好。Windows 移植版的 Redis 不会自动创建dir参数指向的目录，如果目录不存在，服务启动时会因为无法写入 RDB 文件而失败，报错信息同样很含糊。

2.3 安装包获取与校验

下载渠道就一个原则：用官方归档渠道拿包。拿到压缩包之后，养成校验哈希的习惯，尤其是从第三方转存的链接下载的包。校验命令：

certutil -hashfile Redis-x64-5.0.14.1.zip SHA256

把输出的哈希值和官方公布的对比，一致再用。这一步看起来多余，但确实有人因为拿到来路不明的包，装完之后系统里多了一堆莫名其妙的计划任务。花三十秒校验，省掉后面两小时的清理。

解压的时候，用系统自带的解压功能或者 7-Zip 都行，但要注意：解压完成后确认redis-server.exe存在且能被双击识别，如果双击报"不是有效的 Win32 应用程序"，说明包本身损坏或者架构不对，重新下载。

3. 手把手安装：从手动启动到注册服务

3.1 先手动启动一次，别急着注册服务

这一步是很多人跳过的，也是导致后面排查困难的根源。正确的顺序是：先手动跑通，再注册服务。手动跑通了，说明配置、目录、端口都没问题，那么注册服务后如果启动失败，问题范围就缩小到"服务层面的环境差异"上，排查效率完全不一样。

手动启动命令，在D:\Redis\bin目录下执行：

redis-server.exe ..\conf\redis.windows.conf

注意这里的路径写法。用相对路径能跑通的前提是你的工作目录正确，所以我更推荐直接用绝对路径：

D:\Redis\bin\redis-server.exe D:\Redis\conf\redis.windows.conf

启动成功的标志是控制台打印出 Redis 的 ASCII 标识图，下面跟着端口号、PID、配置文件路径三行信息。这时候控制台窗口不能关，关了服务就停了。另开一个窗口，用客户端连一下：

D:\Redis\bin\redis-cli.exe -h 127.0.0.1 -p 6379

进去之后敲ping，返回PONG就说明通了。再敲set testkey hello和get testkey，验证读写正常。最后shutdown nosave或者直接 Ctrl+C 停掉手动实例，准备注册服务。

注意：注册服务之前，一定要先把手动启动的实例停掉。否则服务启动时会因为 6379 端口被占用而失败，而报错信息只会告诉你"服务无法启动"，不会告诉你端口冲突。这个坑我见得太多了。

3.2 redis.windows.conf 关键参数逐条拆解

配置文件是整件事的核心，我按重要性逐条讲，每一条都说清楚"为什么这么设"。

bind 127.0.0.1 port 6379 timeout 0 tcp-keepalive 300 loglevel notice logfile "D:/Redis/log/redis.log" databases 16 save 900 1 save 300 10 save 60 10000 dbfilename dump.rdb dir D:/Redis/data requirepass your_password_here maxmemory 512mb maxmemory-policy allkeys-lru appendonly yes appendfsync everysec

bind 127.0.0.1决定谁能连。写127.0.0.1就是只允许本机连，最安全；想让局域网其他机器连，得改成0.0.0.0或者写具体网卡地址。这里有个坑：改成0.0.0.0之后如果不设密码，等于把数据摆在局域网里公开。所以绑定地址和密码这两项必须一起考虑。

port 6379是默认端口，一般不动。如果本机已经有别的实例占着，改成 6380 之类，记得同步改客户端配置。

timeout 0表示连接永不超时。开发环境设 0 方便调试；如果端口暴露在局域网，建议设成 300，让闲置连接自动断开，减少资源占用。

logfile指定日志路径。这一项极其关键——Redis 服务启动失败时，唯一的有效线索就在这里。注意路径用正斜杠/而不是反斜杠\，配置文件里反斜杠是转义字符，写错了会导致日志文件创建失败，进而整个服务启动失败。

save三行是 RDB 持久化的触发条件，含义分别是：900 秒内至少 1 个键变化、300 秒内至少 10 个键变化、60 秒内至少 10000 个键变化，满足任一条件就写一次快照。如果只是本地调试、不关心数据持久性，可以把这三行全部注释掉，能省掉一些磁盘 IO。但要注意，一旦save全注释掉，重启后数据就没了。

dir是工作目录，RDB 和 AOF 文件都存在这里。这个参数是服务启动失败的高频元凶之一，因为服务启动时的工作目录可能和你在命令行里不一样，相对路径会解析到别的地方。所以这里必须写绝对路径。

requirepass设密码。设置之后所有客户端连接都要先auth。这里有个常见误解：以为设了密码，服务就安全了。实际上密码是明文存在配置文件里的，而且如果没开 TLS，网络传输也是明文的。本地开发设一个简单密码足矣，别用生产环境的密码。

maxmemory 512mb限制内存上限。不设的话，Redis 会一直吃内存直到系统扛不住。本地开发建议设 512MB 到 1GB。设了这个参数就必须配maxmemory-policy，否则内存满了之后写入操作会直接报错。

maxmemory-policy allkeys-lru是淘汰策略，含义是内存达到上限时，在所有键里按最近最少使用原则淘汰。除此之外常用的还有volatile-lru（只淘汰设置了过期时间的键）、noeviction（不淘汰，写入直接报错）。纯缓存场景用allkeys-lru，如果数据不能丢就得用noeviction并做好监控。

appendonly yes开启 AOF 持久化，appendfsync everysec表示每秒同步一次磁盘。AOF 比 RDB 更接近实时，但文件体积更大、重启恢复更慢。我的习惯是：本地调试只开 RDB，需要保存重要测试数据时再开 AOF。

3.3 注册为 Windows 服务并设置自启

配置确认无误、手动启动验证通过之后，就可以注册服务了。命令如下，注意用管理员身份执行：

D:\Redis\bin\redis-server.exe --service-install D:\Redis\conf\redis.windows.conf --loglevel verbose

这条命令的每个部分都有讲究。--service-install是安装服务的动作；紧跟的配置文件名必须给全路径，否则服务启动时会去默认位置找配置，找不到就用内置默认值；--loglevel verbose表示安装过程输出详细日志，方便确认服务注册到了哪一步。

安装成功后，命令行不会有华丽提示，只打印一行服务注册成功的信息。这时候去"服务"管理器（services.msc）里找，能看到一个名为Redis的服务，启动类型默认是"自动"。

配套的几个命令记牢：

# 启动服务 D:\Redis\bin\redis-server.exe --service-start # 停止服务 D:\Redis\bin\redis-server.exe --service-stop # 卸载服务 D:\Redis\bin\redis-server.exe --service-uninstall

需要说明的是，--service-uninstall卸载服务之后，注册表里可能还有残留项。彻底清理用系统命令：

sc query Redis sc delete Redis

sc query先确认服务状态，sc delete再删。如果sc delete报"指定的服务未安装"，说明已经清干净了。

另外一个很实用的操作：如果修改了配置文件，必须重启服务才生效。重启命令就是先--service-stop再--service-start。改配置不重启，然后抱怨"改了没用"，这是新手最常见的自我怀疑来源。

3.4 端口放行：局域网访问绕不过去的一步

如果需要让局域网里其他机器连过来，光改bind是不够的，Windows 防火墙还得放行 6379 端口。图形界面操作路径是"控制面板 - 系统和安全 - Windows Defender 防火墙 - 高级设置 - 入站规则 - 新建规则"，选"端口"，填 TCP 6379，允许连接。

命令行方式更快，管理员权限下执行：

netsh advfirewall firewall add rule name="Redis 6379" dir=in action=allow protocol=TCP localport=6379

放行之后，在另一台机器上用telnet 你的IP 6379测试连通性。如果不通，先确认防火墙规则生效，再确认bind改对了，最后确认两台机器在同一网段。三步下来基本能定位。

注意：局域网放行加不加密码，是两个完全不同的安全等级。Redis 早期版本有未授权访问的历史问题，端口一旦对外开放，必须设requirepass，并且密码不要用123456这类弱口令。

4. Redis 服务无法启动的排查实录

这一章是全文的重点。服务启动失败的报错信息永远只有一句话，但背后的原因至少有十来种。我的排查方法固定是四步：看日志、查端口、验配置、看权限。

4.1 第一步永远是看日志，别瞎猜

日志文件位置就是配置文件里logfile指定的路径。如果那个文件不存在，说明 Redis 连日志都没写出来就挂了，问题出在更早的阶段。这时候有两个备选查看点：

一是事件查看器。eventvwr.msc打开，进"Windows 日志 - 应用程序"，找来源为Redis或者Application Error的条目。服务管理器启动失败时，Windows 一定会在这里留下痕迹。很多在日志文件里看不到的东西，事件查看器里有。

二是控制台直接启动看输出。把服务停掉，用命令行手动启动一次，报错会直接打在屏幕上，比翻日志快得多：

D:\Redis\bin\redis-server.exe D:\Redis\conf\redis.windows.conf

常见的输出信息对应关系是这样的：Can't chdir to 'D:/Redis/data'说明 dir 目录不存在或者路径写错；Opening the temp file for AOF rewrite后面跟错误说明 AOF 文件有损坏；Warning: no config file specified说明配置文件没被读到；Creating Server TCP listening socket *:6379: bind: No error这一类通常意味着端口被占用。

看到报错之后先别急着改，先确认这个报错是不是完整的。有些错误是连锁的，第一个错误解决了，后面的才暴露出来。我的习惯是把报错原文复制到一个临时文本里，逐条排除。

4.2 报错现象对照表

把常见情况整理成一张表，遇到问题先对号入座。

这张表的用法是：先看现象落在哪一行，然后按解决方向走。如果现象不在表里，回到 4.1 看日志，日志会告诉你更多。

4.3 三类高频坑：端口、路径、权限

端口冲突是占比最高的一类。排查命令：

netstat -ano | findstr :6379

如果输出里有LISTENING状态的记录，后面那列数字就是占用进程的 PID。用下面的命令查是什么程序：

tasklist | findstr 12345

把 12345 换成实际的 PID。常见的情况是：之前手动启动的 Redis 实例没关掉，或者另一个 Redis 服务实例还在跑。解决办法就是先停掉占用方。如果确认是残留的 Redis 进程，用taskkill /PID 12345 /F强制结束，然后再启动服务。

这里有个隐蔽情况：netstat显示 6379 被占用，但tasklist查不到对应程序，或者显示的是系统进程。这通常是端口处于TIME_WAIT状态，属于正常的连接回收过程，等一两分钟自动释放。不用慌。

配置路径问题排第二。它的表现形式非常迷惑：命令行手动启动一切正常，注册成服务就失败。原因就是前面提到的——服务启动时的工作目录不是你执行命令的目录，配置里所有相对路径都会解析到C:\Windows\System32之类的系统目录下。所以dir、logfile、dbfilename这些涉及路径的参数，一律写绝对路径，并且用正斜杠。

还有一个更细的点：注册服务时如果没指定配置文件全路径，服务会使用内置默认配置。这时候你改了半天redis.windows.conf，服务压根没读它。判断方法很简单，看日志文件有没有生成——如果服务用的默认配置，logfile默认是空字符串，日志会打到标准输出而不是文件，你在文件系统里找不到任何日志。

权限问题排第三，也是最容易被忽略的。表现形式是目录存在、路径正确、端口也通，但服务就是起不来。原因是服务运行身份对data目录没有写权限。解决办法有两种：一是给data和log目录添加NETWORK SERVICE或者LOCAL SERVICE的完全控制权限；二是把服务的登录身份改成当前管理员账号。图形界面在"服务 - 属性 - 登录"里改，命令行用sc config Redis obj= ".\Administrator" password= "你的密码"。

我个人的偏好是第一种，因为改服务登录身份会引入密码管理的麻烦，密码一改服务就起不来。给目录加权限更彻底。

4.4 启动后马上停止：几种不常见但很致命的原因

除了上面三类，还有几种情况出现频率低但杀伤力大。

RDB 文件损坏。上一次启动时异常断电或者被强杀，RDB 文件写了一半，下次启动读取时直接失败。这时候日志里会明确写 RDB 读取错误。处理办法：先备份dump.rdb，然后用检查工具：

D:\Redis\bin\redis-check-rdb.exe D:\Redis\data\dump.rdb

如果确认损坏无法修复，删掉这个文件重新启动，代价是丢失上次快照之后的数据。本地开发环境基本无所谓。

AOF 文件损坏。AOF 是追加写的，如果写入过程中中断，文件末尾会有半条命令，启动时解析失败。修复命令：

D:\Redis\bin\redis-check-aof.exe --fix D:\Redis\data\appendonly.aof

这个工具会把文件末尾不完整的命令截掉，通常能救回来。修复前记得备份原文件。

磁盘空间不足。这个原因最容易被忽略，因为错误信息五花八门。Redis 启动时要写 RDB 或者 AOF，磁盘满了就写不进去，服务启动失败。检查一下D:\Redis\data所在分区剩余空间，留出至少几 GB 的余量。

系统内存紧张。如果maxmemory设得比实际可用内存还大，或者机器本身内存占用已经很高，Redis 启动时分配内存失败，服务就起不来。这种时候日志里可能只有一行很简短的错误。把maxmemory调到合理值，或者关掉一些占内存的程序。

配置文件编码问题。这个坑非常阴间：用某些编辑器保存redis.windows.conf时，默认存成了带 BOM 的 UTF-8 或者带 CRLF 换行的格式，Redis 解析时把 BOM 头当成了非法字符。表现就是手动启动无反应或者报配置解析错误。解决办法是把文件另存为不带 BOM 的 UTF-8 或者 ANSI。我踩过一次，查了两个小时，最后用十六进制查看器才发现文件头多了三个字节。

5. 客户端连接验证与基础调优

5.1 命令行与图形化客户端双验证

服务起来了不代表能用，必须实际连一次。命令行验证用redis-cli：

D:\Redis\bin\redis-cli.exe -h 127.0.0.1 -p 6379 -a your_password

-a后面跟密码。注意命令行里带密码会在 shell 历史里留痕，更规范的做法是连进去之后用auth命令认证：

D:\Redis\bin\redis-cli.exe -h 127.0.0.1 -p 6379 127.0.0.1:6379> auth your_password OK 127.0.0.1:6379> ping PONG 127.0.0.1:6379> info server

info server会输出一大堆信息，重点看redis_version、uptime_in_seconds、tcp_port三项。uptime_in_seconds数字很小说明服务刚重启过，如果这个数字一直是几秒钟，说明服务在反复重启，问题没解决。

图形化客户端方面，Redis Desktop Manager 这一类工具用起来直观，能看到键的树形结构和值的内容，调试时很方便。选工具的时候注意一点：客户端版本和服务端版本差异太大时，某些新命令会报错，这是因为客户端不认识新命令的返回值格式，不是服务端的问题。遇到这种情况，用redis-cli再验证一次就能区分。

连接成功之后有个必做的动作：进客户端看一下databases数量对不对。默认 16 个库，如果配了别的数字，客户端要能识别。有些客户端默认只连 0 号库，切库要用select 1命令。

5.2 持久化方案怎么选：RDB 还是 AOF

这是配置阶段最需要动脑子的地方，两个方案不是二选一的关系，可以同时开。

RDB 是定期快照，把整个内存数据 dump 成一个二进制文件。优点是文件紧凑、恢复快、对性能影响小；缺点是快照之间的数据会丢。比如 60 秒触发一次快照，结果第 59 秒断电，这 59 秒的写入就没了。

AOF 是追加日志，每次写命令都记录到文件里。优点是丢失窗口小（everysec模式下最多丢 1 秒），缺点是文件体积大、恢复慢。AOF 文件会随着时间不断增长，需要靠重写机制压缩，重写过程本身也消耗资源。

我的建议是分场景：本地开发调试，只开 RDB，甚至把save全注释掉，反正数据不重要；需要保留重要测试数据的，开 AOF 加everysec；做性能压测的时候，两个都关掉，避免磁盘 IO 干扰压测结果。

还要注意一个参数：appendfsync。它有三个取值，always表示每条命令都同步磁盘，最安全但性能最差；everysec每秒同步，折中方案；no交给操作系统决定，性能最好但可能丢较多数据。生产环境一般用everysec，本地开发用no也完全没问题。

5.3 maxmemory 与淘汰策略的配套计算

maxmemory设多少，不能拍脑袋。合理的思路是：看机器总内存，减去操作系统占用、减去你开发用的 IDE 和其他工具的内存，剩下的再打个七折给 Redis。比如 16GB 内存的机器，系统加常用软件占 6GB，剩 10GB，Redis 给 512MB 到 1GB 就够本地开发用了，没必要给太多。

设置之后一定要配maxmemory-policy。如果不配，默认是noeviction，内存一满，所有写操作都返回错误，表现为"读取正常、写入全失败"，很有迷惑性。

127.0.0.1:6379> config get maxmemory 127.0.0.1:6379> config get maxmemory-policy 127.0.0.1:6379> info memory

info memory能看当前内存使用量、内存碎片率。碎片率长期高于 1.5 说明内存碎片比较多，可以考虑重启服务整理，或者调整分配器参数。本地环境不用太在意这个指标。

另外推荐开启慢查询日志：

slowlog-log-slower-than 10000 slowlog-max-len 128

10000的单位是微秒，也就是记录超过 10 毫秒的命令。slowlog-max-len是保留条数。查看慢查询：

127.0.0.1:6379> slowlog get 10

本地开发时这个配置能帮你快速发现写坏了的命令，比如误用keys *扫全库。

6. 实操心得与常见问题速查

6.1 我踩过的几个坑，你可以少走点弯路

第一个坑，改了配置忘记重启。这个坑我踩过不止一次，改完maxmemory直接在客户端用config get验证，发现还是旧值，然后开始怀疑配置文件没生效，折腾半天才想起来服务根本没重启。后来我养成了习惯，所有配置修改都用命令行改一次（config set），确认生效后再同步写回配置文件，重启服务做最终验证。这样两步走，既有即时反馈，也保证了持久化。

第二个坑，--service-install会写系统注册表。这个操作不是纯文件层面的，卸载的时候如果只删目录不卸载服务，系统里会留一个指向不存在路径的服务项，每次开机都报错。所以正确的卸载顺序是：先--service-uninstall，再sc delete确认删干净，最后删目录。顺序反了就要手动去注册表里清理，麻烦得很。

第三个坑，bind 0.0.0.0加上没设密码，然后完全忘记这件事。后来某天发现本地 Redis 里多了一堆不认识的键，才知道局域网里有人扫到了。所以绑定地址和密码必须成对考虑，改一个就检查另一个。

第四个坑，用中文注释写配置文件。Redis 的配置解析器对非 ASCII 字符处理得不好，注释里带中文有可能导致解析失败。现在我写配置文件一律用英文注释，或者干脆不写注释，配置说明单独放在一个 README 里。

第五个坑，把 Redis 装在了带空格的路径下，服务能注册成功但启动时报参数错误。这个我在 2.1 提到了，这里再强调一次，路径干净比什么都重要。

6.2 日常维护速查表

这张表我贴在显示器边上过很长一段时间，现在基本背下来了。其中config rewrite那个特别值得说一句：如果之前一直是手动改配置文件，那么config set改的参数在重启后就丢了，用config rewrite可以把当前运行时的配置回写进文件，避免两边不一致。

6.3 迁移与卸载：别留下尾巴

迁移到另一台机器，需要拷的就是三个东西：conf目录、data目录、以及bin目录下的可执行文件。前提是目标机器上的目录结构保持一致，否则配置文件里的绝对路径要全部改一遍。所以我现在的习惯是配置文件里所有路径全部用统一前缀，迁移时整批替换，比一条条改快得多。

卸载的完整流程写清楚：

# 1. 停止服务 D:\Redis\bin\redis-server.exe --service-stop # 2. 卸载服务 D:\Redis\bin\redis-server.exe --service-uninstall # 3. 确认服务已删除 sc query Redis # 4. 如果还有残留，强制删除 sc delete Redis # 5. 删除防火墙规则 netsh advfirewall firewall delete rule name="Redis 6379" # 6. 最后才删目录

第 5 步容易被忘，防火墙规则不会随目录删除而消失，留着一条指向不存在程序的规则没意义，顺手清掉更干净。

最后分享一个小技巧：如果你经常需要在"手动启动调试"和"服务方式运行"之间切换，可以写两个批处理文件放在桌面，一个负责停服务并前台启动，方便看实时日志；一个负责停掉前台实例并启动服务，方便日常使用。这样切换成本降到双击一次，比每次敲一长串命令舒服太多。这个做法我在好几台开发机上都用过，实测下来很省事。