ss -tunp 是唯一不依赖 lsof 且能同时获取 PID 与连接状态的通用命令，但需 root 权限查看其他用户进程，普通用户仅能查自身进程；过滤时应使用 sudo ss -tunp | grep "pid=12345," 避免误匹配。
用 ss -tunp 按 PID 过滤连接，但得先知道进程 PID
直接查某个进程的 TCP 连接数，核心是把进程和 socket 关联起来。ss -tunp 是唯一能在不依赖 lsof 的前提下拿到 PID 和连接状态的通用命令，但它要求你提前知道目标进程的 PID（或至少能用 pgrep 精准匹配）。
常见错误是直接跑 ss -tunp | grep nginx——如果 nginx 是以非 root 用户运行，普通用户执行时会看到 users:(("nginx",pid=12345,fd=6)) 这样的字段，但前面那行可能被权限截断，grep 会漏掉；更糟的是，ss -tunp 默认需要 root 权限才能显示所有进程的 users: 字段，非 root 用户只能看到自己启动的进程。
- 先确认 PID：
pgrep -f "python app.py"或pidof nginx，避免用模糊的ps aux | grep引入干扰行 - 再查连接：
sudo ss -tunp | grep "pid=12345," | wc -l（注意逗号和等号，防止匹配到其他数字） - 如果不想用
sudo，且确定进程属于当前用户，可用：ss -tunp | grep "users:.*12345," | wc -l，但部分内核版本会省略users:前缀，这时就不可靠
lsof -p PID -iTCP 更直观，但不是所有环境都装了
lsof 输出可读性高，-iTCP 限定协议，-p 锁定进程，组合起来就是最直白的“这个进程开了几个 TCP 连接”。但它在 Alpine、CentOS Stream 最小镜像、或某些容器中默认不存在，且对非 root 用户无法读取其他用户的 socket。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 检查是否可用：
command -v lsof，返回空就得先装：CentOS 用yum install -y lsof，Alpine 用apk add lsof - 统计数量：
lsof -p 12345 -iTCP | wc -l，但要注意第一行是表头，真实连接数要减 1；更稳妥写法是lsof -p 12345 -iTCP | grep -v "COMMAND" | wc -l - 如果只关心 ESTABLISHED 状态，加
-sTCP:ESTABLISHED参数：lsof -p 12345 -iTCP -sTCP:ESTABLISHED，避免把 LISTEN 或 TIME_WAIT 算进来
绕过权限限制：从 /proc/PID/fd 提取 socket inode 再反查
当既没 lsof 也没 root 权限，又必须确认某个进程的 TCP 连接数时，唯一可靠路径是走 /proc。每个 socket 在 /proc/PID/fd/ 下是一个符号链接，指向 socket:[inode]，而所有 socket 的 inode 都记录在 /proc/net/tcp 和 /proc/net/tcp6 中。
- 列出进程所有 fd 中的 socket：
ls -l /proc/12345/fd/ 2>/dev/null | grep socket: - 提取 inode 号：
ls -l /proc/12345/fd/ 2>/dev/null | grep socket: | sed -r 's/.*socket:\[([0-9]+)\].*/\1/' | sort -u - 在
/proc/net/tcp*中查这些 inode 是否处于 ESTABLISHED：awk '{if ($10 == "01") print $NF}' /proc/net/tcp /proc/net/tcp6 2>/dev/null | grep -Ff - （实际操作中建议分步，避免一行写崩）
这方法零依赖、不需 root，但步骤多，容易在字段对齐或 hex 状态码（如 01 表示 ESTABLISHED）上出错；真正卡住的地方往往不是命令本身，而是没意识到 /proc/PID/fd/ 下的 socket 链接可能被进程主动关闭后还残留几秒，导致数量虚高。
