ss是首选，因其为内核socket接口直接封装，不依赖procfs解析，速度快、延迟低、输出稳定；netstat则易在高并发时卡顿或漏项，权限不足时还可能返回空结果。
直接结论：优先用 ss -tulnp，次选用 lsof -i :端口号；netstat 仅在旧系统或容器里不得已才用。
为什么 ss 是首选？它比 netstat 快且更准
现代 Linux（2018 年后主流发行版）默认启用 ss，它是内核 socket 接口的直接封装，不走 procfs 解析，延迟低、输出稳定。而 netstat 依赖遍历 /proc/net/ 下多个文件，遇到高并发连接时容易卡顿或漏项。
常见错误现象：netstat -tulnp 返回空，但服务明明在监听；或者 grep :8080 没结果，实际 curl localhost:8080 能通——这往往是因为 netstat 权限不足或解析超时，而 ss 不会。
-
ss -tuln就能列出所有监听端口（不含进程名），无需 root -
sudo ss -tulnp | grep :3306输出中users:((“mysqld”,pid=1234,fd=32))直接带 PID 和 fd 号，比netstat的PID/Program name字段更可靠 - IPv6 默认混在输出里，加
-4可强制只看 IPv4：sudo ss -tulnp4 | grep :80
lsof -i :端口号 能看到什么 netstat/ss 看不到的
lsof 把端口当“打开的文件”处理，所以它能暴露更多上下文：比如进程是用哪个用户启动的、是否绑定了特定网卡、甚至连接状态（ESTABLISHED 还是 LISTEN）。
典型使用场景：你发现 ss 显示某个端口被占用，但 PID 对应的进程 ps 查不到——大概率是容器内进程或已僵死但文件描述符未释放，这时 lsof 的 USER 和 COMMAND 列能帮你快速识别来源。
-
sudo lsof -iTCP -sTCP:LISTEN -P -n：只列 TCP 监听端口，不反解服务名和主机名，提速明显 -
sudo lsof -i :22：查 SSH，输出含ssh进程名、PID、用户、IP 绑定地址（如127.0.0.1:22或*:22） - 没装？
yum install lsof（CentOS/RHEL）或apt install lsof（Debian/Ubuntu）
netstat -tulnp 还值得学吗？只在三个地方绕不开
不是它过时，而是它的行为在新环境里更容易出偏差。但以下情况你躲不开：
- 某些精简容器镜像（如
alpine基础镜像）默认没ss和lsof，只有netstat（需apk add net-tools） - 排查路由表或组播成员时：
netstat -r或netstat -g仍是唯一选择 - 需要按协议统计丢包/重传：
netstat -s -p tcp输出比ss -s更细粒度
注意：netstat -p 在非 root 用户下常为空，因为无法读取 /proc/PID/exe；而 ss -p 同样受限，但至少 ss -tuln 不依赖权限就能看端口状态。
查到 PID 后，别只靠 ps -ef|grep 就完事
拿到 PID（比如 1234）后，ps -ef | grep 1234 只能看命令行片段，容易误判。真正关键的信息藏在 /proc 下：
-
cat /proc/1234/cmdline：原始启动参数，含完整路径和配置文件位置 -
ls -l /proc/1234/cwd：进程当前工作目录，对调试脚本类服务极有用 -
readlink /proc/1234/exe：真实二进制路径，可区分软链接和实际程序（比如python3指向哪个版本） -
sudo lsof -p 1234：看该进程打开了哪些文件、端口、socket，比单查端口更全面
最容易被忽略的一点：有些进程（如 systemd 服务）的 PID 会因重启变化，但它的 Unit 名称不变。查到 PID 后，顺手跑一句 systemctl status 1234，往往比翻日志更快定位服务归属。
