PHP 8.0 内存溢出主因是旧代码在新环境被放大，如未释放PDOStatement、大数组累积、闭包隐式引用，叠加JIT加速使GC问题提前暴露；需分层排查：定位峰值（插memory_get_peak_usage）、清理资源（unset/destroy/disconnect）、改缓冲为流式查询、清除ini_set硬覆盖。
PHP 8.0 项目出现内存溢出，往往不是版本本身更耗内存，而是老写法在新环境里被“放大”——比如未释放的 PDOStatement、循环中不断追加的大数组、闭包捕获对象后没解绑，加上 JIT 编译让内存增长更快、GC 更早暴露问题。排查优化要分层推进：先确认真实瓶颈，再针对性清理资源、调整数据流、修复隐式泄漏。
快速定位内存峰值和爆点位置
别只看报错里那行 Allowed memory size of ... exhausted——它只是最后一根稻草。重点是找出哪段代码让内存持续爬升：
- 在脚本关键节点插入
echo "Step X: " . memory_get_peak_usage() . "\n";，尤其查库前后、大循环起始/结束、Excel 解析完成时 - 临时关闭 xdebug（
php -d zend_extension= -f script.php），排除调试扩展干扰 - 删掉所有
var_dump()、print_r($huge_data)、未清理的日志输出，它们常偷偷把整个对象树塞进内存 - 运行
get_included_files()看是否加载了上百个文件——自动加载失控或重复 require 也会吃光内存
主动释放显式资源与大变量
PHP 不会等你离开作用域才回收，尤其含资源句柄或对象引用时。必须手动干预：
- PDO 查询完立刻
unset($stmt)，避免游标残留；不要只unset($this->pdo)就以为安全——若其他地方还存着该对象引用（比如传给了闭包、塞进了全局数组），unset无效 - CLI 脚本处理大批数据时，每轮循环末尾明确
unset($row, $item, $tempArray)，比依赖 GC 更可控 - 解析 Excel、读取大 JSON 后，及时
unset($spreadsheet)或调用$spreadsheet->disconnectWorksheets()，否则 worksheet ↔ workbook 的双向引用会锁死内存 - GD 图像处理后必须
imagedestroy($image)；DOMDocument 处理完建议显式调用$dom->clear()
改掉缓冲查询，用流式读取替代全量加载
Db::select("SELECT * FROM huge_table") 是典型内存杀手。ThinkPHP 5/6 默认走缓冲查询，整张表拉进内存才返回；PHP 8.0 下 JIT 加速反而让这一步更快“炸”：
立即学习“PHP免费学习笔记（深入）”；
- TP8 直接用
Db::cursor()替代Db::select()，它已默认关闭缓冲 - TP5/6 或原生 PDO，必须手动设置：
$pdo->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, false)，并确保PDO::ATTR_EMULATE_PREPARES => false - 游标循环里禁止再调
find()查关联数据——那又绕回全量加载；改用 JOIN 或提前批量查好 ID 列表再 in 查询
检查并清理 ini_set('memory_limit') 的硬覆盖
很多老项目在入口文件、公共函数或测试引导文件里写了 ini_set('memory_limit', '256M')。这个调用优先级高于 php.ini 和 Docker 环境变量，在 CLI 下会直接覆盖你配的 2G，导致实际只剩 128M：
- 全局搜索：
grep -r "ini_set.*memory_limit" --include="*.php" . --exclude-dir=vendor - 重点检查
tests/TestCase.php、bootstrap/app.php、自定义服务提供者 - 验证当前生效值：在脚本开头加
echo ini_get('memory_limit') . "\n"; - CLI 运行时最可靠方式：
php -d memory_limit=1G script.php，无需重启服务
