用ps和pgrep命令行组合精准定位高内存node进程：先筛选node/npm/yarn进程并排除grep自身，再按%mem或rss排序识别真实占用者，重点检查脚本路径与运行时长，避免code helper等干扰。
Mac终端中排查占用大量内存的Node进程，需绕过活动监视器图形界面，直接用命令行定位真实PID与内存开销，避免被Code Helper渲染进程干扰主逻辑进程判断。
用ps精准筛选所有Node相关进程
打开终端，执行：ps -axu | grep -E "(node|npm|yarn)" | grep -v grep。
这一步会列出所有含 node、npm、yarn 字样的用户进程，排除掉 grep 自身产生的临时行；注意看 USER 列是否为当前账户名，【跳过 root 或 _www 等系统用户启动的 node 进程，它们通常不属于你的开发环境】。
若输出过长，可追加 | less 分页查看，按空格翻页，按 q 退出。
按实际内存排序并识别高占进程
执行以下命令，按物理内存（%MEM）降序排列所有 node 进程：
ps -axu | grep -E "(node|npm|yarn)" | grep -v grep | sort -k4,4nr | head -10
第4列是 %MEM，-k4,4nr 表示按第4字段数值逆序排列；head -10 只显示前10条——真正吃内存的往往就在前三名里。重点关注 CMD 列末尾是否带具体脚本路径（如 node ./server.js），而不是笼统的 node 或 node /usr/local/bin/npm。
如果某 node 进程 %MEM 超过 30%，且已运行数小时未重启，大概率存在未释放的定时器、闭包引用或缓存堆积。
用pgrep + ps组合获取精确内存值
方法一：查出所有 node 进程 PID 后补全内存详情
先运行 pgrep -f "node.*\.js\|server\.js\|app\.js"，匹配你项目中常见的入口文件名；输出是一串数字，每个都是 PID。
再把结果传给 ps 查内存：`ps -o pid,vsz,rss,%mem,comm -p $(pgrep -f "node.*\.js")`。
这里 RSS（Resident Set Size）才是真正驻留物理内存的字节数，比 %MEM 更准；VSZ 是虚拟内存总量，超过 2GB 就要警惕内存泄漏。
方法二：一次性查出 RSS 最高的那个 node 进程
ps -eo pid,rss,comm --sort=-rss | grep "node" | head -1。
这条命令全局扫描所有进程，按 RSS 从高到低排，只取第一个 node 相关条目——适合快速锁定“罪魁祸首”。
