必须用sudo lsof -i :端口号，否则仅显示当前用户进程，root或其他用户服务（如nginx、docker-proxy）会被遗漏；输出中PID、USER、COMMAND字段可直接识别占用进程类型。
查端口占用必须用 sudo lsof -i :端口号
不加 sudo 只能看到当前用户启动的进程，root 或其他用户的监听服务（比如 nginx、docker-proxy）会直接漏掉。输出里第二列是 PID，第三列是 USER，第四列是 COMMAND——一眼就能分辨是开发服务器、数据库还是容器转发在占端口。
如果提示 command not found，说明没装：sudo apt install lsof（Debian/Ubuntu）或 sudo yum install lsof（RHEL/CentOS）。别用 netstat：多数新系统默认不带，且权限处理不稳定；也别依赖 ss -tulnp 查进程名——它在普通用户下常显示为空白，不是命令写错，是内核权限限制。
kill PID 前先看 ps -p PID -o pid,ppid,cmd
拿到 PID 后别急着 kill -9。很多场景下，PID 对应的是子进程（如 Node cluster 的 worker）、已僵死但 socket 未释放的父进程，或者根本是容器内部的 PID（lsof 输出里 COMMAND 是 containerd 或 docker-proxy 就得进容器查）。
-
ps -p PID -o pid,ppid,cmd,%mem,%cpu能看到完整命令行和父进程 ID，确认是不是你刚起的npm start或python -m http.server - 如果是
java进程，cmd字段通常包含 JAR 名或主类，比只看进程名靠谱得多 - 若
PPID是 1，说明可能已被 init 接管，杀之前得再核对一次
优先发 SIGTERM（kill PID），不是 kill -9 PID
kill PID 默认发信号 15（SIGTERM），给进程机会关闭监听套接字、清理临时文件、断开数据库连接。大多数现代服务（nginx、gunicorn、spring-boot）收到后几秒内就干净退出。
只有两种情况才升级到 kill -9 PID：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
lsof -i :端口号仍显示该 PID 在 LISTEN，且ps -p PID显示状态为R（持续运行无响应）或<defunct></defunct>（僵尸进程） - 你明确知道这个进程没有优雅退出逻辑（比如某些 C 写的裸 socket 程序）
kill -9 不触发任何清理，socket 会卡在 TIME_WAIT 状态约 60 秒——这不是端口没释放，是 TCP 协议设计如此。此时 ss -tuln | grep :端口号 若显示 TIME-WAIT，可直接复用端口（只要应用 bind 时设了 SO_REUSEADDR）。
慎用 lsof -t -i :端口 | xargs kill -9
这条命令看着高效，实则危险：
-
-t只输出 PID，xargs kill -9会无差别强杀所有匹配项，包括刚 fork 出来的子进程、同一端口上不同用户的守护进程 - 它不区分
LISTEN和ESTABLISHED连接，可能把正在传请求的连接也干掉 - 若端口被多个服务共用（比如
HAProxy+Nginx轮询），会误杀非目标服务
真要批量操作，先用 lsof -iTCP -sTCP:LISTEN -P -n | grep :端口 锁定 LISTEN 状态的进程，再逐个确认。
最易被忽略的一点：杀完进程后 lsof -i :端口 还有输出，未必是进程没死——可能是内核残留的 TIME_WAIT，也可能是你查的是 IPv6 地址（lsof -i6 :端口 才能看见），还可能是容器网络映射导致宿主机看不到真实 PID。别一招鲜吃遍天，得根据 COMMAND 和 TYPE 字段动态判断下一步该进容器、改配置，还是等内核自动回收。
