PHP 8.0 内存泄漏需分层定位：先确认请求后内存是否未回落，再锁定对象循环引用、扩展不兼容或WeakMap误用等源头，最后通过GC调试、快照分析和针对性修复解决。
PHP 8.0 网站内存泄漏不是“某个开关一关就消失”的问题，而是要分层定位：先确认是否真泄漏、再锁定泄漏源头（是代码结构？扩展不兼容？还是误用缓存？），最后针对性修复。关键不在于堆内存数字涨了，而在于请求结束后内存没回落——这才是泄漏的标志。
看懂内存变化趋势，别被瞬时峰值误导
用 memory_get_usage() 和 memory_get_peak_usage() 在关键节点打点，比如控制器入口、DB查询后、Excel加载前、响应返回前。重点观察：
- 单次请求结束时，内存是否回到接近初始值？若每次请求后残留 2–5MB 并持续累积，就是典型泄漏
- 在 CLI 模式下循环执行同一接口 100 次：
for ($i=0; $iindex(); }，配合gc_collect_cycles()后仍不回落，基本可确认存在引用滞留 - 避免只看
top或htop中的 PHP 进程 RSS，它包含共享库、OPcache 等静态开销；专注脚本级动态内存增长
查三类高频泄漏源：对象引用、扩展冲突、缓存滥用
PHP 8.0 下最常“卡住”内存的不是业务逻辑本身，而是三类隐性强引用：
-
循环引用未解耦：如
$user->profile和$profile->owner都是强引用。即使unset($user)，两个对象仍互相拽着不释放。必须改用WeakReference::create($user)存反向关系，并通过->get()安全访问 -
扩展读取 zval 失效：Swoole < 4.6.0、Xdebug < 3.0.0、旧版 Redis 扩展在 GC 扫描时可能因 PHP 8.0 的 zval 结构变更（如
refcount__gc偏移变化）触发非法内存访问，表现为 segfault 或进程静默退出。运行php -m列出扩展，重点升级这些组件 -
WeakMap 误当通用缓存：写成
$cache['user_123'] = $data是错的——WeakMap 键必须是对象实例，且仅靠对象身份索引。若用字符串作键，它退化为普通数组，对象生命周期被意外延长。正确用法：$cache[$userObj] = $meta;，之后unset($userObj)，条目自动消失
用工具链快速定位泄漏对象
不依赖猜测，用 PHP 自带能力抓“活证据”：
立即学习“PHP免费学习笔记（深入）”；
- 启用 GC 调试：在 php.ini 加
zend.gc_debug=1，重启后调用gc_status()查看"roots"数量。长期运行服务中若该值 > 3000，说明大量对象待检测，GC 扫描压力大，容易漏回收 - 导出内存快照：CLI 下运行
php -d zend.enable_gc=1 -r "gc_collect_cycles(); var_dump(gc_status());"，对比多次执行后"collected"是否稳定增长。若几乎为 0，说明有对象始终无法进入 roots 队列，大概率是扩展绕过 GC 或 zval 损坏 - 检查 OPcache 影响：修改配置后
config('app.name')不更新？可能是 OPcache 缓存了 runtime/config.php。先执行php think config:clear，再用opcache_reset()清空字节码缓存
修复动作要落在具体操作上
排查清楚后，修复不是改一个参数，而是组合动作：
- 对长期运行的服务（如 Swoole Worker），禁用自动 GC：
zend.enable_gc = 0，改用定时gc_collect_cycles()+gc_disable()控制节奏 - 读 Excel 时不用
IOFactory::load()，改用流式读取：$reader->setReadDataOnly(true); $reader->setLoadSheetsOnly(['数据表']); - 所有手动
ini_set('memory_limit', ...)必须从测试启动文件、中间件、BaseTestCase 中彻底删除——它会覆盖 Docker 环境变量设置，导致 PHPUnit 固定卡在 128M - Session 配置检查：TP8.0 默认
'secure' => true，HTTP 环境下浏览器拒收 Cookie，表面是“登录失效”，实则是 Session ID 每次都新建，旧 session 文件堆积不清理，间接造成磁盘和内存压力
