PHP本地环境无内置资源监控，需用ps/grep快速定位高耗脚本，或在代码中嵌入memory_get_usage()和microtime()精确测量，配合htop树形视图观察进程关系。
PHP 本地环境（如 XAMPP、MAMP、Docker 中的 php-fpm 或 php -S）本身不自带资源监控能力，必须依赖系统级工具或轻量级 PHP 扩展辅助观测。直接看 top 或 htop 只能看到进程整体占用，无法区分是哪个 PHP 脚本、哪个请求在吃 CPU 或内存——这正是本地调试时最常卡壳的地方。
用 ps + grep 快速定位高耗 PHP 进程
适用于所有类 Unix 系统（macOS/Linux），无需安装额外工具，能立刻看到正在运行的 PHP 脚本及其资源消耗：
-
ps aux --sort=-%cpu | grep php：按 CPU 占用倒序列出 PHP 进程，一眼识别“卡死”的脚本 -
ps aux --sort=-%mem | grep 'php\|fpm'：重点看php-fpmworker 或php -S子进程的内存使用 - 注意
ps输出中的COMMAND列，它会显示完整命令行，比如php /var/www/test.php或php-fpm: pool www，可直接对应到具体文件 - Windows 用户可用
tasklist /fi "imagename eq php.exe"，但无法显示参数路径，信息有限
在 PHP 脚本内嵌 memory_get_usage() 和 microtime(true)
适合调试单个页面或 CLI 脚本，精准定位某段逻辑的资源开销，避免被其他并发请求干扰：
echo "Memory before: " . memory_get_usage() . " bytes\n"; $result = some_heavy_function(); echo "Memory after: " . memory_get_usage() . " bytes\n"; $start = microtime(true); slow_database_query(); $end = microtime(true); echo "Query took: " . ($end - $start) . "s\n";
-
memory_get_usage(true)返回实际分配的内存（含未使用的内存块），比默认更准确 - 不要只看峰值，关注「增长量」：比如一个循环中每轮增加 2MB，100 轮就是 200MB 泄漏
- CLI 模式下建议加
gc_collect_cycles()后再测内存，否则可能掩盖引用计数问题
用 htop 配合 PHP 进程树观察父子关系
当使用 php-fpm 或 Apache + mod_php 时，一个请求可能触发多个子进程，htop 的树状视图能看清调用链：
立即学习“PHP免费学习笔记（深入）”；
- 启动
htop，按F5切换树形模式 - 找到主进程（如
php-fpm: master process），展开后可见 worker 进程及其当前执行的脚本路径（如果procfs可读） - 按
F6排序选PRESSURE（CPU）或MEM%，快速聚焦异常节点 - 注意：Docker 容器内默认看不到宿主机进程树，需以
docker exec -it <container> htop进入容器内部运行
为什么不用 sys_getloadavg()？
sys_getloadavg() 返回的是系统平均负载（1/5/15 分钟），不是当前 PHP 进程的实时资源占用。它对本地开发几乎无用：
- 值受所有系统进程影响，哪怕你只跑一个
php -S，后台更新、杀毒软件也会拉高负载 - Mac 和 Linux 实现不一致，macOS 上该函数常返回
[0,0,0] - 无法关联到具体 PHP 请求，不能用于性能瓶颈定位
真正需要的是进程粒度的观测，而不是系统统计值。本地调试时，优先盯住 ps 输出和脚本内插桩，比任何“监控平台”都快、都准。
