用管理员CMD执行netstat -ano | findstr :6379获取PID，再用tasklist | findstr PID定位进程；注意WSL2、Docker或服务残留可能造成误判，改配置前需确认实际加载的redis.windows.conf及服务注册状态。
怎么快速确认6379端口被谁占了（Windows）
直接打开管理员权限的 cmd，两行命令就能定位：先查端口，再查进程。别跳过“管理员权限”，否则 tasklist 可能看不到系统级进程。
-
netstat -ano | findstr :6379—— 输出类似TCP 0.0.0.0:6379 0.0.0.0:0 LISTENING 12345，最后那个数字就是 PID -
tasklist | findstr 12345—— 把上一步的 PID 填进去，看是哪个程序，比如redis-server.exe、java.exe或 Docker 的com.docker.backend.exe
常见误判：看到多个 redis-server.exe 就以为是自己启重了，其实可能是 WSL2 里的 Redis、Docker 容器、或旧版 Redis 服务残留 —— 不要盲目 kill，先看清楚。
改配置文件前先搞清用的是哪个 conf
Windows 下 Redis 启动时默认不读 redis.conf，而是优先找同目录下的 redis.windows.conf（尤其从 Microsoft Archive 下载的版本）。如果你改了 redis.conf 却没生效，大概率是启动时根本没加载它。
- 启动命令是
redis-server.exe redis.windows.conf？那就必须改这个文件里的port行 - 如果直接运行
redis-server.exe（没带参数），它会用内置默认配置，此时改任何 conf 都无效 - 检查是否已注册为 Windows 服务：运行
sc query redis，若状态是RUNNING，那服务用的配置路径得查注册表或服务属性，不是你当前目录下的 conf
改完保存后，务必关掉所有 redis-server.exe 进程（任务管理器里搜一下），再重新执行启动命令，否则旧进程还在占端口。
连接时指定新端口，但别漏掉 -h 参数
改完端口后，用 redis-cli.exe 连不上？大概率是因为默认只连 127.0.0.1:6379，而你已经改成 6380 了，但没告诉客户端。
- 正确写法：
redis-cli.exe -h 127.0.0.1 -p 6380——-h和-p必须同时显式写，不能省 - 错误写法：
redis-cli.exe -p 6380—— 此时它仍会尝试连localhost:6379，因为-h缺失时 fallback 行为不一致，Windows 下尤其容易失效 - 验证是否通：连上后输入
PING，返回PONG才算真通；别只看命令行没报错就以为成功
注意：如果 Redis 是作为服务运行的，改完 conf 后得用 net stop redis && net start redis 重启服务，而不是手动起 redis-server.exe —— 否则服务和你手动启的实例会冲突。
为什么有时候改了 port 还是连不上
端口改了，配置也 reload 了，redis-cli 还是连超时？问题往往不在 Redis 本身，而在绑定地址或防火墙。
- 检查
bind配置项：如果 conf 里写了bind 127.0.0.1，那它只响应本地回环请求；若你从 WSL、Docker 或另一台机器连，就得加bind 0.0.0.0或删掉这行（不推荐生产环境） - Windows 防火墙默认拦新端口：哪怕你改到 6380，系统也可能把它当未知应用拦截。临时关防火墙测试下，或手动放行该端口
- Redis 启动时没输出错误日志：加个
--loglevel verbose参数启动，看控制台是否提示Could not create server TCP listening socket—— 那说明端口还是被占，或者 bind 失败
最常被忽略的一点：改完 conf 后没检查 Redis 实际监听的端口。用 netstat -ano | findstr LISTENING 看一眼，确认它真在你设的那个端口上 LISTENING，而不是静默失败后退回到 6379 或干脆没起来。
