排查内存泄露这事儿，最要紧的是先确认问题真实存在，而不是一上来就翻代码。PHP日志文件是最直接的线索来源——Apache下一般在 /var/log/apache2/error.log，Nginx则在 /var/log/nginx/error.log。翻日志时，重点关注两类信号：
- 显式错误提示：像
Fatal error: Allowed memory size of X bytes exhausted这样的记录，说明某个脚本耗尽了分配的内存限额，这往往是泄露的典型标志。 - 内存使用趋势：用
grep把日志里跟内存相关的行筛出来（比如grep "memory_get_usage" /path/to/php_error.log），如果发现多次请求或脚本执行过程中，内存占用只涨不降，那就基本坐实了泄露的存在。
开启并配置PHP内存日志
要精准追踪内存消耗，得先在PHP脚本里打开详细的日志记录。PHP自带的 memory_get_usage() 能返回当前内存占用的字节数，memory_get_peak_usage() 则给出脚本执行期间的内存峰值。把它们插在关键节点——脚本启动时、数据库查询后、循环前后——就能看到内存变化的脉络：
// 记录起始内存
$start_memory = memory_get_usage();
error_log("Memory usage at start: " . $start_memory . " bytes", 3, "/path/to/php_error.log");
// 你的业务逻辑（数据库调用、循环等）
// 记录关键操作后的内存
$end_memory = memory_get_usage();
$memory_used = $end_memory - $start_memory;
error_log("Memory used after operation: " . $memory_used . " bytes", 3, "/path/to/php_error.log");
这样一来，代码里哪些部分在“吃”内存就一目了然了。如果想更细粒度地控制，还可以在 php.ini 中打开PHP的通用错误日志：
error_reporting = E_ALL
log_errors = On
error_log = /path/to/php_error.log
用系统工具分析日志
等日志里积累了足够的内存数据，命令行工具就能派上用场：
- grep：过滤出内存相关记录，比如
grep "memory_get_usage" /path/to/php_error.log | sort -nr可以按内存使用量从大到小排序。 - awk：直接累计总内存用量，例如
awk '/memory_get_usage/ {sum += $NF} END {print "Total memory used: " sum " bytes"}' /path/to/php_error.log。 - tail：实时监控日志，配合
grep观察高流量时段的内存波动：tail -f /path/to/php_error.log | grep "memory_get_usage"。
进阶工具：深度剖析复杂泄露
有些泄露原因很隐蔽，普通日志分析搞不定，这时候需要上专业工具：
- Xdebug：PHP扩展，能生成内存剖析报告。在
php.ini里配置好：
运行脚本后，用 KCacheGrind 或 QCacheGrind 打开生成的 cachegrind 文件，内存消耗的热点就一目了然。zend_extension=xdebug.so xdebug.mode=profile xdebug.output_dir=/path/to/profiler_output - Blackfire：商业工具，提供实时性能分析。界面友好，能帮你快速定位内存泄露、慢函数和低效代码路径。
- Valgrind：系统级内存检测工具，对编译后的PHP脚本同样有效。加上
--leak-check=full参数就能获得详尽的未释放内存报告：valgrind --leak-check=full php your_script.php。
常见诱因与修复方法
根据日志分析结果，可以从下面几个方向入手排查：
- 未释放资源：数据库连接、文件句柄、网络套接字用完一定要关。比如
mysqli_close($connection)或fclose($file)。 - 循环引用：对象之间互相引用会导致垃圾回收机制失效。用
unset()打断引用链，比如unset($object)。 - 低效的数据结构：别动不动就开大数组，改用生成器（
yield）分批处理数据，内存开销能降一大截。 - 过度使用全局变量：全局变量在整个脚本生命周期中都活着，用多了内存就蹭蹭往上涨，能少用就少用。
- 过期的扩展：旧版PHP扩展可能存在已知的内存泄露问题，升级到最新版本通常能解决。
预防措施与持续监控
与其反复修泄露，不如从一开始就防患于未然：
- 设定内存上限：在
php.ini里给个合理的memory_limit（比如memory_limit = 256M），防止单个脚本把系统内存吃光。 - 启用日志轮转：用
logrotate定期压缩、删除老日志（配置文件放在/etc/logrotate.d/php），避免日志撑爆磁盘。 - 定期重启服务：对长时间运行的PHP-FPM或Web服务器，通过
cron安排定时重启，把累积的内存清理掉。 - 监控系统资源：用
htop、top或free -m实时查看内存使用，再跟PHP日志数据对照着看，更容易发现异常。
