先用ss -tulnp | grep :6379或netstat -tulnp | grep :6379快速验证端口状态；若有输出则显示占用进程及pid，无输出说明端口空闲但需排查redis配置（如daemonize yes）和pidfile问题。
确认6379端口是否被占用
先用命令快速验证端口状态。推荐使用 ss（更现代、轻量）或 netstat：
- ss -tulnp | grep :6379
- netstat -tulnp | grep :6379
如果有输出，说明端口正被监听；末尾的 /redis-server 或其他进程名（如 docker-proxy、java）就是“占用者”。若无输出，则6379未被占用，问题可能出在Redis未启动或配置异常。
定位具体占用进程的PID
只要上一步有结果，就能看到进程ID（PID）。例如输出为：
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 12345/redis-server
其中 12345 就是PID。也可单独查：
- lsof -t -i :6379（直接返回PID）
- fuser 6379/tcp（简洁显示PID）
如果提示 command not found，说明系统未安装 lsof 或 fuser，可改用 netstat/ss + grep 组合，或运行 sudo apt install psmisc（Debian/Ubuntu）或 sudo yum install psmisc（CentOS/RHEL）补全工具。
安全终止或释放端口
拿到PID后，按场景选择处理方式：
- 确认是残留的 Redis 进程 → 执行 kill -9 PID 强制结束
- 怀疑是正常运行的 Redis 实例 → 先尝试优雅停止：kill -15 PID，再检查是否退出
- 发现是 Docker、Java 应用等非 Redis 进程 → 查清用途，非必要不强杀；若确需释放，再 kill
- 多个 PID 占用同一端口（少见但存在）→ 逐个 kill，再用 ss 验证是否清空
执行后务必再次运行 ss -tulnp | grep :6379，确保无输出才表示端口真正释放。
排除配置与守护模式干扰
即使端口空闲，Redis仍可能启动失败。重点检查两项：
- daemonize yes：在 redis.conf 中确认该参数为 yes。若为 no，Redis 启动后前台阻塞，容易被误判为“未启动”，也易因终端关闭导致残留
- pidfile 配置是否有效：检查 pidfile 路径是否存在、权限是否可写。若 Redis 无法写入 pid 文件，可能反复启动失败并残留子进程
可配合 ps aux | grep redis 查看是否有多个 redis-server 进程，尤其注意无配置文件路径或带 --port 参数的异常实例。
