卸载redis折腾记，报错不断关不掉真心累人经历分享

（来源：知乎用户“码农小张”的个人博客分享）

那天我寻思着电脑有点卡，一看磁盘空间快满了，发现是很久以前做测试装的Redis占了不少地方，这东西项目早就做完了，留着也没用，干脆卸了吧，谁能想到，就这么个简单的想法，让我接下来的一下午都泡在了和Redis的“战斗”里,差点没把电脑给砸了。

第一回合：天真的开始与突如其来的报错

我心想，这还不简单？对于Windows系统，找到那个“卸载或更改程序”的面板不就行了？我熟练地打开设置，在应用列表里翻来找去，嘿，奇了怪了，压根就没看到Redis的影子，我这才想起来，当初好像是图省事，直接下载的压缩包，解压后直接运行的，这下好了，没有安装程序,自然也就没有卸载入口。

那我就更直接点呗，我找到当初解压的那个文件夹，想着直接按Delete键把整个文件夹扔进回收站，一了百了，结果，我刚选中文件夹，就弹出一个错误提示，大概意思是“文件正在被另一个程序使用，无法删除”。（来源：操作系统的错误提示弹窗）

第二回合：与“幽灵进程”的缠斗

我第一反应是，是不是我什么时候手滑，又把它打开了？我赶紧呼出任务管理器，在进程列表里一个个找，找了一圈，没发现叫“redis-server.exe”的进程，我不死心，又仔细看了好几遍，甚至还用了搜索功能，确实没有，这就邪门了，明明没看到它在运行,为啥说被占用了呢？

这时候，我想起来可以用命令行试试，我打开cmd，输入了 netstat -ano 命令，想看看有没有什么陌生的端口被占用（我记得Redis默认端口是6379），果然，在长长的列表里，我看到了 0.0.0:6379 这一行，后面跟着一个PID（进程ID），好家伙，果然有东西在偷偷运行！（来源：通过Windows命令行工具排查进程）

我赶紧回到任务管理器，切换到“详细信息”标签页，按照那个PID排序查找，这次终于让我逮到了！这个PID对应的进程名居然不是“redis-server”，而是一个我完全没见过的名字，好像是某个系统服务之类的，我当时就懵了，难道Redis还会“伪装”自己？

我不敢贸然结束进程，怕把系统搞崩了，于是我又上网搜“Redis Windows 卸载”，这才恍然大悟，原来这种绿色版的Redis，如果是以Windows服务的方式安装的，它的进程名就可能不是直观的“redis-server”。（来源：某技术论坛关于Redis服务安装的讨论帖）

第三回合：关闭服务，再起波澜

按照网上的教程，我以管理员身份打开命令行，输入命令 sc delete Redis 想删除这个服务，结果系统提示“指定的服务未安装”，我愣了一下，难道服务名不对？我又试了 sc query type= service 命令，在一大堆服务名称里费力地寻找，终于发现了一个名字特别长的服务，里面带着“Redis”字样，原来安装的时候给它起了个全名！（来源：Stack Overflow上关于SC命令找不到服务的回答）

我重新输入了正确的服务名，这次 sc delete 命令终于显示成功，我长舒一口气，觉得这下总该完事了吧，我再次尝试删除那个Redis文件夹，令人崩溃的是，那个“文件正在使用”的错误提示又弹出来了！我简直要抓狂了，服务都删了,怎么还阴魂不散？

第四回合：终极决战与柳暗花明

我瘫在椅子上，快没脾气了，抱着最后一丝希望，我下载了一个叫“LockHunter”的小工具（来源：网友推荐的文件解锁工具），它可以查看是哪个进程锁定了文件，用它一扫瞄，真相大白！锁住文件的，居然是“Windows 资源管理器”自己（explorer.exe）！工具提示说可能是因为文件句柄没有完全释放。

没办法，我只能按照工具的提示，先解锁文件，然后飞快地按下Shift + Delete（永久删除），趁着系统还没反应过来，把整个文件夹给强删了！看着进度条走完，文件夹终于消失了，我整个人像打了一场硬仗一样,累得不行。

为了保险起见，我还手动清理了注册表里可能残留的Redis相关项（这个步骤非常危险，不熟悉的朋友千万别乱试），并且重启了电脑，重启后，再用 netstat -ano 检查，6379端口终于空闲了，这场耗时两个多小时的Redis卸载大战，总算以我的惨胜告终，经过这一通折腾，我算是明白了，以后装软件再也不图省事用绿色版了，老老实实用安装包,卸载的时候才能省心啊。