/proc/$pid/limits 是内核为进程维护的实时软硬限制快照，三列分别为资源名、软限制（当前生效值）、硬限制（上限）及单位；prlimit 本质是格式化该文件，current 列即软限制，非实时用量；ulimit -a 仅反映当前 shell 会话限制，不适用于 systemd 服务等外部进程；该文件只读，不可写入，修改需 prlimit（root 权限）、setrlimit() 或重启并配置启动上下文。
直接看 /proc/$pid/limits 是最准的
它不是推断值，也不是配置项，而是内核为该进程实际维护的软硬限制快照。每行包含三列：Limit（资源名）、Soft Limit（当前生效值）、Hard Limit（上限），单位也一并标出。比如 Max open files 行告诉你这个进程此刻最多能打开多少文件描述符——不是用户默认值，也不是 shell 会话值，就是它自己被赋予的那个数。
常见错误现象：
你改了 ulimit -n 65536，但新起的进程没继承？先 cat /proc/$pid/limits | grep "open files" 确认目标进程是否真拿到了新值。
输出里显示 unlimited 不代表没限制，可能是硬限制太高、或者被 cgroup/systemd 拦截了，得结合 systemctl show myapp.service | grep LimitNOFILE 查。
prlimit 能查运行中进程的实时限制
prlimit 本质是读取并格式化 /proc/$pid/limits，但它支持按资源名过滤，比手动 grep 更直观：
-
prlimit -p 1234：列出 PID 1234 所有资源限制 -
prlimit -p 1234 --nofile：只看文件描述符限制 -
prlimit -p 1234 --as：只看地址空间（虚拟内存）限制
注意：prlimit 显示的 CURRENT 列不是“当前使用量”，而是软限制值（即 Soft Limit）；它不提供实时用量统计，要看用量得用 /proc/$pid/status 或 cat /proc/$pid/stat 解析。
别信 ulimit -a 对已运行进程的判断
ulimit -a 只反映当前 shell 会话的软限制，对非该会话启动的进程（如 systemd 服务、后台 nohup 进程、容器内进程）完全无效。它甚至不保证子进程继承——如果父进程在 fork 后 exec 前没调用 setrlimit()，子进程拿到的就是内核默认值（通常是 1024 文件描述符）。
典型误用场景：
你在终端执行 ulimit -n 65536，然后 ./myserver & 启动服务，再 ps aux | grep myserver 找到 PID，cat /proc/$pid/limits 却仍显示 1024 ——因为 myserver 是在 ulimit 修改前派生的 shell 的子进程，没继承新值。
正确做法：要么在启动前设好环境，要么用 prlimit -p $pid --nofile=65536:65536 动态补救（需 root 权限提硬限制）。
/proc/$pid/limits 不能直接写入
有人看到路径就以为能 echo 写入，这是危险误解。该文件是只读虚拟接口，echo "Max open files=65536:65536" > /proc/1234/limits 必然报 Invalid argument 或 Permission denied。内核禁止任何写入操作——它只出口，不入口。
真正能改运行中进程限制的，只有：
• prlimit（受权限和内核约束）
• 进程自己调用 setrlimit()
• 重启进程，并确保其启动上下文（shell、systemd unit、容器 runtime）已加载正确的限制配置
普通用户无法看到其他用户的 /proc/$pid/limits，会报 Permission denied；root 才能全量查看。
最容易被忽略的一点：systemd 服务的 LimitNOFILE= 设置会覆盖 prlimit 的修改，且在下次 reload/restart 时重置。如果你发现刚用 prlimit 改完，几秒后又变回原值，大概率是 systemd 在后台拉回了。
