必须加-l参数才能查监听端口，否则netstat默认只显示已建立连接；ss-tuln更快更高效，lsof-i:80直接定位进程但需预装，三者均需sudo权限显示完整进程信息。
netstat、ss 和 lsof 都能查，但默认不显示监听状态的命令会漏掉关键信息——必须加 -l（listen）或等效参数，否则你看到的只是已建立连接，不是“正在等待连接”的端口。
为什么 netstat -tuln 是最稳妥的入门组合
很多新手跑 netstat 没结果，是因为忘了 -l。它只筛选出处于 LISTEN 状态的套接字，这才是“被监听”的准确含义。
不加 -l 时，netstat 默认只显示已建立连接（ESTABLISHED），和监听完全无关。
常见错误现象：执行 netstat -tun 后找不到 80 端口，但 nginx 明明在跑——其实是没加 -l。
-
-t和-u分开看 TCP/UDP，混用可能漏掉 UDP 服务（比如 DNS 的 53 端口） -
-n必须加，否则端口号会被解析成服务名（如http），grep 查数字端口会失败 - 想看到占用进程，得加
-p，但这需要 root 权限；普通用户执行会提示Permission denied或空白 PID 字段
ss -tuln 比 netstat 更快，但输出格式更紧凑
ss 是 netstat 的现代替代，内核态直接读取 socket 信息，没有用户态解析开销，尤其在高连接数服务器上响应明显更快。
它的参数和 netstat 几乎一致，ss -tuln 可直接替换 netstat -tuln 使用。
容易踩的坑：部分旧系统（如 CentOS 6）默认没装 iproute 包，运行 ss 会报 command not found。
- 输出中没有
LISTEN字样，而是用State列显示LISTEN（注意大小写） -
Local Address:Port格式是*:22或[::]:22，IPv6 地址带方括号，grep 时需转义 - 要查进程名，同样需要
-p+ sudo，否则Process列为空
lsof -i :80 能直接定位到进程，但依赖额外安装
lsof 不按协议分类，而是从“打开的文件”角度切入——Linux 中 socket 就是文件，所以 lsof -i :80 会直接列出所有跟 80 端口有关的进程，包括监听和已连接的。
它不区分 LISTEN 和 ESTABLISHED，所以结果可能比你需要的多；加 -sTCP:LISTEN 可过滤（但语法稍绕）。
最大限制：多数最小化安装的云服务器默认不带 lsof，得先 yum install lsof 或 apt install lsof。
- 普通用户运行
lsof -i :80可能看不到 PID，需加sudo -
-nP参数很实用：-n不解析端口名，-P不解析主机名，避免延迟和 DNS 查询干扰 - 查 UDP 端口时，
lsof -iUDP:53比lsof -i :53更精准，后者可能混入 TCP 结果
grep LISTEN 时最容易忽略的细节
很多人用 netstat -tuln | grep 80，却匹配不到结果，其实是因为输出里 Local Address 列可能是 0.0.0.0:80、:::80 或 127.0.0.1:80，而 grep 80 会把 8080、18080 也拖进来，还可能漏掉 IPv6 行。
更可靠的做法是锚定列：netstat -tuln | awk '$4 ~ /:80$/ {print}'，或者用 ss -tuln | grep ':80 '（注意末尾空格，排除 8080）。
-
LISTEN和LISTENING是不同命令的输出写法：netstat用LISTEN，Windows 的netstat -an用LISTENING，别混淆 - 有些服务绑定到
127.0.0.1:port，对外不可达，但仍是监听状态——这不算“未监听”，只是监听范围受限 - 云服务器上还要注意安全组/防火墙策略：端口确实在监听，但外网连不通，往往是策略拦截，不是监听问题
