定时任务中unset()不起作用的主因是变量被闭包捕获、静态引用或循环引用导致gc无法回收；应配合memory_get_usage()验证、gc_collect_cycles()强制回收，并避免静态变量、进程复用及fiber上下文残留。
定时任务中 unset() 不起作用？先确认是否真在释放目标变量
很多 PHP 8.1 定时任务（如 cron 调用的 CLI 脚本）跑着跑着内存持续上涨，一查发现 unset() 像没执行一样。根本原因常是：变量被闭包捕获、静态属性引用、或对象间存在循环引用，导致 GC 无法自动回收。
实操建议：
- 用
memory_get_usage(true)在关键节点打点，确认unset($largeArray)后内存是否真下降——别只信逻辑 - 对大数组/对象，
unset()后立即调用gc_collect_cycles()，强制触发垃圾回收（PHP 8.1 默认启用 GC，但不保证即时） - 避免在循环内反复
new对象却不unset；更稳妥的是改用局部作用域，让变量自然出作用域销毁 - 检查是否用了
static $cache = []—— 静态变量生命周期贯穿整个脚本，unset无效，必须显式赋值为null或空数组
CLI 模式下 memory_limit 为 -1？反而更容易 OOM
PHP CLI 默认常把 memory_limit 设为 -1（无限制），看似安全，实则掩盖问题：内存泄漏不会报错，只会越积越多，直到系统 kill 进程（Killed process 日志就是信号）。
实操建议：
- 在脚本开头用
ini_set('memory_limit', '128M')主动设限（注意：部分托管环境禁用此函数，需改php.ini） - 若必须处理大数据，分批而非全量加载：比如查 10 万条记录，用
while ($row = pg_fetch_assoc($result))流式读取，而不是pg_fetch_all($result) - 对 PostgreSQL 查询结果，处理完立刻调用
pg_free_result($result)，它释放的是 C 层资源，unset()无法替代 - 避免在循环里拼接大字符串（如日志累积），改用
file_put_contents($logFile, $line, FILE_APPEND)直接刷盘
协程（Fiber）里内存不释放？注意 suspend/resume 的上下文残留
用 Fiber 写定时任务时（例如并发拉多个 API），容易忽略：每次 resume() 恢复后，前一次 suspend 的局部变量栈可能未清空，尤其当 Fiber 函数体里有大对象或资源句柄时。
实操建议：
- Fiber 回调函数内，对中间结果数组、临时文件句柄等，务必在
Fiber::suspend()前unset或关闭 - 不要在 Fiber 外部保留对内部变量的引用（例如把
$fiber存进全局数组），这会阻止整个 Fiber 栈被回收 - 调试时加
echo memory_get_peak_usage() . "\n"，观察每次start()和resume()后峰值是否阶梯式上升 - 简单场景优先用普通函数+循环，别为“时髦”硬套 Fiber；它的内存管理比同步代码更难追踪
定时任务重启不等于内存重置？进程复用是隐形陷阱
如果用 Supervisor 或 systemd 管理定时任务，且配置了 autorestart=true 或 Restart=always，看起来是“重启”，实际可能是同一进程复用（尤其使用 fork 模式时），之前积累的内存和静态状态仍在。
实操建议：
- 强制进程退出：脚本末尾加
exit(0)，别依赖自然结束；避免die()被异常拦截 - Supervisor 配置里加
startsecs=0和stopwaitsecs=2，减少进程残留窗口 - 对长期运行的守护进程（非单次 cron），用
pcntl_fork()后父进程pcntl_wait()子进程，确保子进程彻底销毁 - 最保险的做法：每次 cron 调用都用全新 PHP 进程，避免任何复用——这意味着别用常驻内存的框架封装层来跑定时任务
unset 没写，而是变量在哪被悄悄持有了。盯住 memory_get_usage() 和 gc_collect_cycles() 的组合输出，比猜更可靠。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
