Windows 上 Redis 后台启动的四种方案与配置实践

1. 为什么要在 Windows 上后台运行 Redis

1.1 先搞懂 Redis 在本地开发里的角色

Redis 是我见过最“低调”的基础组件。它不会像数据库那样有一堆表结构让你设计，也不会像消息队列那样需要专门部署一套管理系统，但它几乎出现在所有后端系统的核心链路上：接口缓存、登录会话、分布式锁、排行榜、限流计数、异步队列，随便拿一个出来都能讲不少东西。我自己最开始学 Redis 的时候，其实是从缓存开始的，后来项目复杂了，才发现它的数据类型和原子操作能解决很多传统方案很棘手的问题。

但不管 Redis 能干什么，你在 Windows 上做本地开发时都要先过一道坎：让这个服务安稳地跑起来，而且是你不用盯着它，不用每次开机手动点一下也能跑起来。这不是小题大做。开发环境里最烦的事情就是，你写代码写到一半，突然发现缓存连不上，排查半天，最后发现是昨天关机的那个 Redis 窗口忘了重新打开。所以“Windows 版 Redis 本地后台启动”这件事，本质上是在解决开发基础设施的稳定性，让 Redis 成为你电脑上一个“理所当然存在”的服务，而不是一个靠手动维护的临时进程。

1.2 主流的 Windows 版 Redis 选择，别装错

很多人第一次搜“Redis Windows”，会找到各种来源的安装包，版本也是五花八门，其实这是有历史原因的。官方 Redis 长期主要面向 Linux，Windows 版本并不是官方一线维护的产物。早期微软团队曾维护过一个 Windows 移植版，但版本停留在 3.x 左右，后来基本不再更新。目前在 Windows 上大家用得比较多的，是社区维护的 5.0 分支移植版，比如 tporodowski 的 Redis 构建，另外还有 Memurai 这种与 Redis 协议兼容的商业产品，提供免费开发者版本。对本地开发来说，社区维护版已经足够稳定，覆盖了日常用到的命令和持久化能力。

还有两种“非传统”选择：一是通过 WSL 跑 Linux 版 Redis，二是通过 Docker Desktop 跑 Redis 容器。这两种方式更贴近服务器环境，适合想完全模拟线上部署的同学。但如果你只是希望在 Windows 本地快速起一个 Redis，原生 Windows 版仍然是最轻量的方案。我建议做两手准备：日常工作用原生 Windows 版，如果项目对 Redis 版本有特殊要求，或者你想体验 Sentinel、Cluster 这类集群玩法，再上 Docker 或 WSL。

1.3 前台启动与后台启动，差的不只是那个黑窗口

如果你已经试过双击redis-server.exe，应该能理解我说的“黑窗口”是什么感受。进程起来了，日志一行一行往外刷，服务也正常使用，但这个窗口会一直停留在任务栏里，你不敢随手关掉，还得注意别误点。更麻烦的是，如果希望通过 SSH 或远程桌面操作那台电脑，黑窗口还会占用一个会话，看起来特别不专业。

后台启动的意思，是让 Redis 不再依赖一个可见的命令行窗口，而是作为系统层面的一个后台进程，或者由系统服务管理器来托管。这样你有几方面的好处：第一，窗口被关闭不会导致 Redis 挂掉；第二，可以配置开机自启，不用每次手动执行；第三，服务如果异常退出，可以通过系统机制自动拉起或记录日志；第四，终端环境是干净的，不会时不时弹出一个黑窗口打断思路。理解了这一点，后面选择哪种方案，就看你希望 Redis 以什么形式存在于系统里了。

2. 下载安装与启动前的准备，5 分钟搭好基础环境

2.1 下载社区维护的 Windows 版本，解压就能用

Windows 版 Redis 的安装体验很接近绿色软件。你下载的是一个 zip 压缩包，解压到本地目录就能运行，不需要执行 installer。我习惯把它解压到C:\Redis，这样路径短，命令好敲。解压后你会看到这些文件：redis-server.exe、redis-cli.exe、redis-benchmark.exe、redis-check-aof.exe、redis-check-dump.exe，以及两个配置文件：redis.conf和redis.windows-service.conf。

第一次接触 Redis 的朋友可能不理解，为什么一个压缩包里会有两个配置文件。其实redis.conf对应手动执行服务的场景，而redis.windows-service.conf是专门为注册成 Windows 服务准备的，里面默认设置了一些适合服务运行的参数，比如通过日志文件记录输出，而不是往控制台打印。下载完建议先手动执行一次redis-server，看到版本号和端口日志，确认这个压缩包在你机器上能正常运行，再继续后面的配置。有个细节要提醒：杀毒软件可能对 Windows 版 Redis 报风险，因为它是非官方签名程序，建议从可靠的 GitHub Release 页面下载，并在文件校验后放行。

2.2 把 Redis 目录加入 PATH，让 redis-cli 随处可用

后台启动之后，你日常打交道最多的其实是redis-cli，而不是redis-server。所以我很早就养成一个习惯，把 Redis 所在目录加到系统 PATH 环境变量里。这样一来，不管你在哪个目录下打开终端，都可以直接执行redis-cli，不用每次输入完整的C:\Redis\redis-cli.exe。

操作步骤很简单：右键“此电脑”，进入“属性 → 高级系统设置 → 环境变量”，在“系统变量”里找到Path，点击编辑，新建一行，填入C:\Redis，保存后重新打开终端。然后执行redis-cli -v，如果能输出版本信息，说明 PATH 配置成功了。这件事看起来只是节省了几次输入，但在后面反复连接、测试 Redis 的时候，效率差距会很明显。我还习惯把数据目录也规划好，比如在C:\Redis下建一个data目录，专门存放 RDB 快照和 AOF 日志，避免 Redis 把持久化文件散落在根目录。

2.3 认准 redis.conf 和 redis.windows-service.conf 的区别

这两个文件的区别是很多人踩坑的起点。手动执行redis-server时，如果你不指定配置文件，Redis 会使用内置默认参数；但你也可以显式指定redis-server C:\Redis\redis.conf，让进程读取这个文件。而注册 Windows 服务时，一般推荐使用redis.windows-service.conf，这个文件中的日志输出、路径定义更适合在后台服务环境里运行。

有朋友会遇到这样的问题：明明改了redis.conf里的端口，可启动后端口还是默认的 6379。原因多半是进程启动时并没有去读redis.conf，或者他注册服务时没有把配置文件路径作为参数带进去。我的建议是，无论用哪种启动方式，都要在命令行里显式把配置文件路径写全，不要依赖当前目录。注册服务时尤其重要，因为服务是由系统来启动的，它的工作目录不是你当时运行命令的那个目录，不写绝对路径就会出问题。后面我们讲注册服务的命令时会再强调这一点。

3. 本地后台启动的四种方案，按需选择

3.1 方案一：注册成 Windows 服务，最省心的后台启动方式

我把这个方案放在第一位，因为它是我在实际开发环境里最推荐的方式。Windows 服务由系统服务管理器托管，可以设置开机自启，可以在“服务”面板里直观地看到运行状态，还能配置失败后自动重启。相比其他方案，它最接近真正的“后台服务”。

注册命令需要以管理员身份打开 CMD 或 PowerShell，然后进入C:\Redis，执行：

redis-server --service-install redis.windows-service.conf --service-name RedisLocal

这条命令的意思是用redis.windows-service.conf作为配置，把 Redis 注册成一个名为RedisLocal的 Windows 服务。你可以换成别的服务名，但建议语义清晰，方便以后认出。注册成功后，再执行启动命令：

redis-server --service-start --service-name RedisLocal

这时候可以打开任务管理器里的“服务”面板，或者运行services.msc，找到RedisLocal，确认状态是“正在运行”。然后打开另一个终端，执行redis-cli ping，如果能返回PONG，说明服务已经正常接收请求了。以后电脑重启，这个服务会自动启动，你完全不用管它。如果要彻底卸载服务，记得先停止再执行：

redis-server --service-stop --service-name RedisLocal redis-server --service-uninstall --service-name RedisLocal

我自己用这套方案跑了很久，稳定性很好。唯一要留意的是，注册服务后，Redis 的进程是由系统账户启动的，如果配置文件中引用的日志目录或数据目录不存在，或者没有读写权限，服务会启动失败。所以尽量用本地磁盘上的绝对路径，不要用网络驱动器。

3.2 方案二：用任务计划程序实现开机自启

如果你不想把事情提升到“服务”这么正式的级别，也可以借助 Windows 的任务计划程序，让 Redis 在开机时自动运行。这个方案的好处是比较灵活，能指定运行用户、控制运行频率，也不需要在系统服务里留下注册项。

我常用的是命令行方式创建计划任务。下面这条命令会在每次系统启动时，以系统身份运行 Redis：

schtasks /create /tn "RedisLocalTask" /tr "C:\Redis\redis-server.exe C:\Redis\redis.windows.conf" /sc onstart /ru SYSTEM /rl HIGHEST schtasks /run /tn "RedisLocalTask"

/tn是任务名，/tr是要执行的程序及参数，/sc onstart表示机器启动时触发，/ru SYSTEM表示使用系统账户。如果你更习惯图形界面，就运行taskschd.msc，创建任务，触发器选“计算机启动时”，操作选“启动程序”，程序填写C:\Redis\redis-server.exe，添加参数填写配置文件绝对路径，再勾选“使用最高权限运行”。

这个方案有个特点，Redis 进程会以可见窗口还是隐藏窗口的方式运行，取决于计划任务配置。如果你是普通用户登录，计划任务如果配置为“只在用户登录时运行”，窗口可能会闪现一个黑框。如果配置为“不管用户是否登录都要运行”，则会在后台运行。这也是为什么我在用这个方案时，更推荐 GUI 配置里把“不管用户是否登录都要运行”选中，同时把配置文件里的logfile打开，把输出写到日志文件里，否则出了问题很难看到错误信息。

3.3 方案三：VBS 脚本隐藏窗口，轻量但没那么可靠

如果你是临时想启动一个不占窗口的 Redis，又不想建立服务或计划任务，可以写一个 VBS 脚本来隐藏启动窗口。这个思路很朴素：利用 Windows 脚本宿主启动程序时，设置窗口状态为 0，也就是隐藏。脚本内容很简单：

Set ws = CreateObject("WScript.Shell") ws.Run "C:\Redis\redis-server.exe C:\Redis\redis.windows.conf", 0, False

把这段内容保存为start-redis-silent.vbs，放到需要的地方。比如可以放在启动文件夹里，这样每次登录都能自动执行。启动文件夹可以按 Win+R，输入shell:startup打开，然后把脚本的快捷方式放进去。

这个方案最大的优点是轻量，不需要管理员权限，也不会在系统服务里留下任何东西。但缺点也很明显：它没有守护机制，如果 Redis 进程因为某种原因崩溃，没有人会自动拉起它；而且你无法直观地看到 Redis 的状态，只能通过redis-cli ping或连接工具去确认。我自己只用它应对一些临时场景，比如某个项目的本地调试不想污染主 Redis 的端口配置时，我不会把它当成长期解决方案。另外，隐藏窗口意味着你失去了 Ctrl+C 正常停止的路径，停止 Redis 只能靠redis-cli shutdown来触发，这一点要先想好。

3.4 方案四：通过 WSL 跑一套原生 Redis

如果你想用 Linux 环境下的原生 Redis，又希望它和 Windows 开发环境无缝配合，WSL 是目前比较优雅的办法。Redis 本身在 Linux 上的表现更稳定，很多高级特性、版本迭代也是优先面向 Linux，所以 WSL 方案能让你体验更接近生产环境的使用方式。

首先确保你的 Windows 已启用 WSL。打开 PowerShell，执行wsl --install，按提示安装一个发行版，比如 Ubuntu。完成之后在 Ubuntu 终端里执行：

sudo apt update sudo apt install redis-server sudo service redis-server start

如果能看到 Redis 启动成功的日志，就可以在 Windows 终端里执行redis-cli ping来测试。WSL2 的网络模式默认会把 Linux 里的服务映射到 Windows 的 localhost 上，所以端口 6379 通常可以直接访问。想让 Redis 开机自启，可以在 WSL 里配置 systemd，或者通过/etc/rc.local加入启动命令。

这个方案的优点是更通用，以后你写出的配置、踩过的坑，基本可以直接迁移到 Linux 服务器上。缺点也很明确，WSL 本身是一层虚拟化环境，内存占用和启动速度都不如原生 Windows 版轻量。如果你的机器配置一般，或者只是想在本地快速做个 PHP 或 Java 项目的缓存测试，我建议还是优先用方案一或方案二。如果你已经深度使用 WSL，那用 Redis on WSL 会让整个开发栈更统一。

4. 后台启动后的配置、连接与排障，照着做就行

4.1 关键配置项一次改到位，避免本机内存被吃满

很多 Windows 用户启动 Redis 后会忽略配置，结果就是 Redis 占用的内存越来越大，电脑越来越卡。因为 Redis 默认情况下，只要不设置maxmemory，就会尽可能使用可用内存，这在本地开发环境是非常危险的。我一般在redis.windows-service.conf里必改这几个地方：

bind 127.0.0.1 port 6379 protected-mode yes maxmemory 256mb maxmemory-policy allkeys-lru appendonly yes appendfilename "appendonly.aof" dir "C:/Redis/data/" logfile "C:/Redis/logs/redis.log"

bind 127.0.0.1保证服务只监听本机，避免局域网里其他设备连上来；protected-mode yes配合bind一起用，能挡住很多误操作；maxmemory 256mb是我给本地开发环境定的常见值，你可以根据自己电脑调整；maxmemory-policy allkeys-lru表示内存达到上限后，按最近最少使用算法淘汰键，适合大多数缓存场景。

有个细节值得注意：Windows 版 Redis 对daemonize是不生效的，因为 Windows 没有 Linux 那种 fork 守护进程机制。你不需要在配置里纠结要不要把daemonize设成 yes，后台化这件事交给服务或计划任务来处理就行。另外，配置里任何路径都建议写成绝对路径，因为服务启动时的当前目录不是固定的。

4.2 用可视化客户端和 redis-cli 验证服务状态

服务启动后，你总得验证它是真起来了还是假起来了。最快速的方式是命令行：

redis-cli -h 127.0.0.1 -p 6379 ping

如果返回PONG，说明服务正在正常响应。这个命令我用得最多，尤其是在改完配置重启服务后，第一条命令永远先 ping 一下。

如果你想看数据，命令行也能满足大多数需求。redis-cli进入交互模式后，可以执行keys *查看所有键，info memory查看内存信息，config get maxmemory查看当前运行时的配置值。不过可视化客户端对于日常管理更友好，用得比较多的是 Redis Desktop Manager 和 Another Redis Desktop Manager。后者的启动速度更快，UI 也更现代。新建连接时填127.0.0.1，端口6379，如果有密码就在 Auth 里填上。连上之后，你能直接看键值对、TTL、内存统计，比在一堆命令里翻找舒服多了。

需要提醒的是，很多连接超时问题，其实不是 Redis 本身的问题，而是你连接时用的地址或端口不对。比如服务只绑定了127.0.0.1，你却用局域网 IP 去连，那肯定超时。如果出现类似redis command timed out的报错，先回来看服务监听地址是不是没覆盖到你访问的那个网卡。

4.3 端口占用、防火墙和连接超时的排查顺序

后台服务跑着跑着突然连接不上，这是很常见的情况。我一般按下面这个顺序排查，能省下不少时间。

先看端口监听状态。打开 CMD，执行：

netstat -ano | findstr 6379

如果看到TCP 127.0.0.1:6379和对应的 PID，说明 Redis 在监听。如果没有输出，说明进程根本没起来，或者用了别的端口。如果端口被其他程序占用，你会看到状态不是LISTENING，或者 PID 对应的进程不是 Redis。这时候可以继续执行tasklist | findstr 进程号查看进程名，再用taskkill /PID 进程号 /F关掉它。这里呼应了很多人说的 Windows 关闭端口号的操作，本质上就是找到占用端口的进程，再决定是放行还是终止。

确认端口没被占用后，再测试本机连接：redis-cli -h 127.0.0.1 ping。能通就说明 Redis 进程没问题，问题出在防火墙或远程访问规则上。Windows 防火墙在 Redis 首次监听端口时可能会弹提示，如果点了取消，后面所有局域网设备都无法连接。可以在“高级安全 Windows Defender 防火墙”里手动添加入站规则，放行 TCP 6379。当然，仅限本地开发的话，我建议干脆把bind保持为127.0.0.1，不开放远程反而更安全。

4.4 把日志文件打开，出问题不再两眼一抹黑

后台运行的最大弊端是没有控制台输出，因此日志就变成了救命稻草。我建议在配置里把logfile设置成一个固定路径，比如C:/Redis/logs/redis.log。注意目录必须提前创建，否则 Redis 启动时写不了日志，服务可能会直接失败。设置好之后，每次启动、连接变动、错误告警都会记录到这个文件里。

遇到启动失败，先打开日志文件。常见错误有这么几类：

如果你注册的是 Windows 服务，还可以打开事件查看器，在“Windows 日志 → 系统”里检索RedisLocal相关的事件，也能看到服务状态变化。不过大多数时候，Redis 自己的日志就已经把问题说得很明白了，我每次排查都先看这个，再去碰系统日志。

5. 从“能启动”到“用得稳”，这些进阶能力值得提前了解

5.1 密码保护和网络绑定，别把 Redis 暴露出去

后台启动意味着 Redis 会常驻运行，这也意味着你不能再把它当成一个临时起、用完关的玩具进程。很多本地开发者一开始没有设置密码的习惯，结果 Redis 就成了网络里最脆弱的服务之一。我在配置里永远会加一行：

requirepass yourpassword

加了之后，命令行连接需要这样写：

redis-cli -h 127.0.0.1 -p 6379 -a yourpassword

不过直接把密码放在命令行里会留在 shell 历史里，所以更推荐在命令行窗口设置环境变量REDISCLI_AUTH，这样redis-cli会自动读取并用于认证。可视化客户端连接时，也要同步填写密码。设置密码之后，分布式锁、缓存读写这些代码里的连接串也要跟着改，别只改 Redis 配置，结果应用连不上了。

除了密码，网络绑定也同样重要。如果你确定 Redis 只给自己本机的应用使用，bind 127.0.0.1就够了。如果你是需要本机局域网内另一台机器调试，比如手机连同一个 Wi-Fi，测试某个接口要访问电脑上的 Redis，那可以把bind改成0.0.0.0，但一定要保证requirepass已启用，并且防火墙只放行可信来源。不要图省事把密码留空直接绑0.0.0.0，这是个很危险的环境。

5.2 数据类型、缓存治理与分布式锁，这些热词背后的逻辑

既然是学习 Redis，数据结构和它背后的用途肯定是绕不开的。很多人面试时被问到的 Redis 数据类型，其实不只是“知道五种类型叫什么”，而是要在实际场景里选对。字符串类型适合做普通缓存、计数器；哈希类型适合存对象信息；列表类型适合做简单的消息队列或时间轴列表；集合类型适合做标签、去重；有序集合适合做排行榜和延迟队列。理解这些，才能在缓存治理中判断哪个键该用什么结构。

缓存治理这个词听起来很大，落到本地开发里其实也很直接。缓存穿透就是大量请求一个不存在的数据，每次都打到数据库；缓存击穿是某一个热点数据的缓存过期，瞬间所有请求涌进来；缓存雪崩是大量缓存在同一时间失效，导致数据库崩溃。Redis 里的空值缓存、热点数据不过期、过期时间加随机抖动，都是针对这些问题的常见思路。分布式锁则是利用 Redis 的原子操作，比如SETNX加上过期时间，确保多个进程同时执行某个任务时，只有拿到锁的那个进程能进入临界区。

这些内容不是后台启动的必修课，但我想说的是，你在 Windows 上把 Redis 作为本地服务稳定跑起来之后，就有了一个可以随时练习这些场景的沙盒。本地起一个实例，做点实验，比看多少文档都有效。

5.3 持久化配置怎么选，重启后数据还在吗

后台启动之后，你会逐渐关心一个问题：我把数据写进 Redis，重启电脑或者重启服务，数据还在吗？默认情况下，Redis 会采用 RDB 快照机制，按一定条件保存数据库状态到磁盘。Windows 版一般配置里已经带了save 900 1、save 300 10、save 60 10000这样的规则，意思是在 900 秒内有 1 个键变化，或者 300 秒内有 10 个键变化等情况下，会触发一次快照。

如果你需要更可靠的数据记录，可以开启 AOF 追加日志。我推荐同时开启两者：RDB 负责定期快照，恢复时速度快；AOF 负责记录每次写操作，最多丢失几秒的数据。在配置文件中，把appendonly yes打开，然后设置appendfilename和dir。需要提醒的是，AOF 文件会随着写入增长，Redis 会自动执行BGREWRITEAOF进行重写，所以不用太担心文件无限膨胀。

验证持久化是否生效，可以这样做：往 Redis 里写入一个测试键，然后通过redis-cli shutdown正常停止服务，再启动服务，执行keys *，如果数据还在，说明持久化配置没问题。这里有个坑，如果你直接强制结束进程或用taskkill /F，RDB 和 AOF 可能还没有写入完整，重启后会丢数据。后台上线之后，尽量都用redis-cli shutdown触发优雅退出。

6. 实操中踩过的坑，以及我现在推荐的启动姿势

6.1 权限不足导致的启动失败，别栽在细节上

我在给一台 Windows 机器配置 Redis 服务时，遇到过两次非常典型的权限问题。第一次是把 Redis 解压到了C:\Program Files目录下，系统对这个目录有严格的权限保护，服务账户虽然没有明确表示拒绝，但日志文件根本写不进去，结果服务启动后马上退出。第二次是配置文件里的dir指向了一个移动硬盘，系统服务启动时可能还没有挂载移动设备，Redis 尝试写持久化文件时直接报错。

所以我现在都建议把 Redis 放在一个纯本地盘的普通目录，比如C:\Redis，不要放在需要管理员权限的 Program Files 下，也不要放在 U 盘或网络路径。数据目录和日志目录提前建好，可以在配置里指定绝对路径，但最好先手动验证一下当前登录用户能正常读写这个路径。如果你注册的是 Windows 服务，服务默认是 LocalSystem 或 NetworkService 身份，很多普通用户的目录它反而不一定友好，用独立的本地目录最省心。

6.2 配置文件没生效，先检查服务运行时用的哪个配置文件

有朋友问我，为什么改了redis.conf里的密码，可redis-cli连接时不输入密码也能通。我让他看一眼服务注册命令，果然他注册服务时用的是redis.windows-service.conf，而改密码却改在了redis.conf。这两个文件在同一个目录，但是服务启动时读的是前者，你的改动当然不会生效。

判断 Redis 到底用了哪个配置文件，有几个办法。一是redis-cli config get dir，看当前数据目录是不是你预期配置文件里设置的目录；二是redis-cli config get maxmemory，如果返回的值和你改的配置文件对不上，说明当前运行的进程没有读那个文件。更直接的办法是重新注册服务，在命令中显式指定你要的配置文件。以后不管注册服务还是计划任务，启动命令里一定要带上配置文件的完整路径，这是避免“改了没生效”最关键的习惯。

6.3 服务启动后连不上，我给你一个排查顺序

后台运行的好处是稳定，但一旦连不上，会觉得比前台黑窗口还难下手。原因很简单，没有窗口看日志，也没法直接知道进程卡在哪。我总结了一个固定排查顺序，你可以照着走一遍。

先看进程是否存在，打开任务管理器，找redis-server.exe。如果不存在，去服务管理面板看RedisLocal服务状态，是停止还是启动失败。如果是启动失败，打开redis.windows-service.conf里指定的logfile日志文件，看启动时的最后几行。如果进程存在，执行netstat -ano | findstr 6379看端口是否监听。监听正常就执行redis-cli ping，如果提示Could not connect，检查 Redis 配置文件里的bind和port，确认没有绑定到一个当时还不存在的网卡地址上。

有一种情况很隐蔽，就是 Windows 防火墙规则里匹配了 6379 端口，但被误设成只允许某些 IP 访问。本地连接还好，远程连接时就特别明显。遇到这种情况，先临时禁用该入站规则试一下，排除是防火墙拦路，再细化 allow 规则。不用一上来就关掉整个防火墙，那会引入更多麻烦。

6.4 我现在最常用的后台启动组合

反复折腾这些方案之后，我自己现在的组合其实挺简单：Windows 上装一个社区维护版 Redis，注册成服务，服务名RedisLocal，配置文件固定用C:\Redis\redis.windows-service.conf，日志写在C:\Redis\logs\redis.log，数据目录在C:\Redis\data。设置maxmemory 256mb、开启 AOF、绑定127.0.0.1，密码只在确实需要外部访问的时候才设置，否则本地开发环境每次都输密码也有点烦。

如果你更追求接近生产环境，我的建议是直接用 WSL。付出多一点点的环境配置成本，但换来的是与 Linux 服务器一致的 Redis 行为和指令，后面接触集群、哨兵这些功能时会更顺畅。至于 VBS 脚本方案，我只在临时需要开第二个 Redis 实例做测试时才会用，不会把它写进系统启动链路里。

后台启动这件事，看着只是一个小技巧，但它直接影响你后面写缓存、做限流、搞分布式锁时的开发体验。先把环境弄稳，让 Redis 安安静静地在你电脑上待命，你才能真正把精力放在业务逻辑而不是启动服务上。