netstat是排查“Address already in use”错误的首选工具，可区分真占用与假冲突：先查LISTEN状态确认是否被监听，再通过PID定位进程，结合TIME_WAIT数量、监听地址（0.0.0.0 vs 127.0.0.1）等细节精准诊断根因。
服务启动时提示“Address already in use”或“端口已被占用”，说明绑定失败，但真正原因不一定是另一个程序在用这个端口。netstat 是第一道排查工具，它能快速区分是“真占用”还是“假冲突”，关键在于看懂输出里的状态、地址和协议细节。
确认端口是否真被监听
先运行命令查看目标端口是否出现在监听列表中：
- Windows：以管理员身份运行 netstat -ano | findstr ":端口号"（如
findstr ":8080"） - Linux/macOS：运行 netstat -tuln | grep ":端口号"（如
grep ":3306"）
如果完全无输出，说明没有进程在监听该端口——不是被占，而是服务根本没起来，或配置了错误的监听地址（比如只绑定了 127.0.0.1 却没写 0.0.0.0）。这时要查服务日志，而不是杀进程。
识别“伪装型”占用：TIME_WAIT 或残留连接
有时 netstat 显示端口没被 LISTEN，但启动仍失败。这很可能是上一个进程关闭后留下的大量 TIME_WAIT 连接，或 socket 未正确释放。这类情况在频繁重启服务时常见：
- Linux 下运行 netstat -an | grep ":端口号" | grep TIME_WAIT | wc -l，若数量远超正常值（如几百上千），说明端口资源被耗尽
- Windows 中可通过 netstat -ano | findstr "TIME_WAIT" 配合端口筛选观察
- 这不是别的程序“抢了端口”，而是系统自身 TCP 状态池暂时不可复用该端口，需等待（默认 2×MSL，通常约 4 分钟）或调整内核参数（如
net.ipv4.tcp_tw_reuse）
查清谁在用：PID 与进程名对应
如果 netstat 明确显示某 PID 正在 LISTEN 或 ESTABLISHED，下一步就是定位进程本身：
- Windows：任务管理器 → “详细信息”页 → 右键列标题 → 勾选“PID”，再按 PID 查找；或直接运行 tasklist /fi "pid eq XXXX"
- Linux：用 ps -p XXXX -o pid,ppid,cmd 或 lsof -i :端口号（更直观，含路径）
- 注意区分：同一端口可能被多个 PID 占用（如 Docker 容器、systemd 服务、用户进程混用），尤其检查是否有旧实例未清理干净
排除监听地址配置陷阱
netstat 输出里 Local Address 一栏决定服务能否被外部访问：
- 看到 0.0.0.0:8080 或 *:8080 → 表示监听所有网卡，可被外网访问
- 看到 127.0.0.1:8080 → 只响应本机请求，远程连不上是正常现象，不是故障
- 看到 192.168.1.100:8080 → 仅绑定到指定网卡，需确认客户端是否在同一子网
这种情况下 netstat 显示“LISTENING”，但客户端 telnet 失败，问题不在端口占用，而在服务配置。修改配置文件（如 Spring Boot 的 server.address=0.0.0.0、Nginx 的 listen 8080 不加 127.0.0.1），重启服务后再验证。
