/proc/$pid/limits 是最准确的进程级资源限制查看方式，它直接反映内核为该进程维护的软硬限制快照，每行含资源名、软限制值、硬限制值及单位，如“max open files 1024 65536 files”。
直接看 /proc/$pid/limits 是最准的，它反映该进程实际生效的软硬限制，不依赖 shell 会话或配置文件是否加载成功。
cat /proc/$pid/limits 显示的是什么
这是内核为每个进程维护的真实限制快照，输出里每行包含三列：Limit（资源名）、Soft Limit（当前软限制）、Hard Limit（对应硬限制），单位和含义都写明了。比如 Max open files 行告诉你这个进程此刻最多能打开多少文件描述符——不是系统全局值，也不是用户默认值，就是它自己被赋予的那个数。
常见陷阱：
- 你改了
ulimit -n 65536，但新起的进程没继承？先cat /proc/$pid/limits | grep "open files"确认目标进程是否真拿到了新值 - 输出里
unlimited不代表没限制，可能是硬限制太高、或者被 cgroup/systemd 拦截了，得结合systemctl show myapp.service | grep LimitNOFILE查 - 普通用户无法看到其他用户的
/proc/$pid/limits，会报Permission denied，root 才能全量查看
prlimit 动态修改运行中进程的限制
prlimit 是唯一能在不重启进程的前提下改 /proc/$pid/limits 的工具，但它受权限和内核约束严格：
- 普通用户只能降低自己的软限制，或把软限制提至当前硬限制范围内；要提高硬限制，必须是 root
- 对 systemd 启动的服务，
prlimit可能被DefaultLimitNOFILE或服务 unit 里的LimitNOFILE=覆盖，改完立刻被拉回 - 子进程不会自动继承父进程被
prlimit修改后的限制，除非显式用fork()+exec()重新加载环境 - 示例：给 PID 1234 提高文件描述符到 16384（软硬一致）：
prlimit -p 1234 --nofile=16384:16384
/proc/$pid/limits 能不能直接 echo 写入
不能。这个路径是只读虚拟文件，echo "..." > /proc/1234/limits 会报 Invalid argument 或 Permission denied。Linux 内核禁止直接写入该文件——它只是状态出口，不是控制接口。
有人误传“echo -n "Max open files=65536:65536" > /proc/1234/limits”可行，那是错的。真正生效的只有 prlimit 或进程启动前由内核/初始化系统设定的值。
如果你看到某文档这么写，大概率是混淆了旧版内核（2.6.32 之前）的调试接口，或把 /proc/sys/ 下可写的参数当成了 /proc/$pid/ 下的。
为什么改了 limits.conf 还不生效
因为 /etc/security/limits.conf 只在登录会话建立时由 PAM 加载，对已运行的进程、非登录方式启动的服务（如 systemd service、docker 容器、cron job）完全无效。
- 验证是否加载：用
loginctl show-user $USER | grep -i limit看 PAM 是否应用了配置 - systemd 服务必须在 unit 文件里显式写
LimitNOFILE=65536，或全局改/etc/systemd/system.conf中的DefaultLimitNOFILE - 容器内进程受宿主机 cgroup 和容器 runtime 限制双重约束，
/proc/$pid/limits显示的是最终叠加结果 - 改完
limits.conf必须新开一个 login shell（比如 ssh 重连），而不是在当前终端source一下就生效
最易被忽略的一点：进程的限制是继承来的，不是“查到哪设到哪”。你要调的从来不是某个孤立的数字，而是整个启动链路上所有可能插手的环节——PAM、systemd、cgroup、容器 runtime、甚至程序自己调用的 setrlimit()。不顺藤摸瓜确认每一层，光盯着 /proc/$pid/limits 看，只会反复陷入“我明明改了，怎么没用”的循环。
