php resource 必须显式关闭，因其不参与引用计数与gc：unset()仅销毁变量容器，不释放底层资源；需调用fclose()等对应函数，否则导致文件描述符等持续泄漏。
PHP 的资源管理不是“写了 unset() 就完事”的线性过程，而是一套分层协作机制：引用计数负责绝大多数即时释放，循环引用靠 GC 周期检测，而资源句柄（如 curl、socket、mysqli）则完全游离于这两者之外——它们不走 zval 引用计数，也不进 GC 根缓冲区，必须显式关闭。
resource 类型不参与引用计数，也不会被 gc_collect_cycles 清理
PHP 中的 resource（如 fopen() 返回的文件指针、curl_init() 返回的句柄）是 C 层级的系统资源封装，其生命周期由底层扩展直接控制。它们的 refcount 恒为 0，unset() 或作用域结束只会销毁 PHP 层的 resource 变量容器，但不会调用 fclose() 或 curl_close()。
- 典型错误：
$fp = fopen('/tmp/log', 'w'); unset($fp);→ 文件描述符未关闭，持续累积直至Too many open files - 正确做法：必须显式调用对应关闭函数，如
fclose($fp)、curl_close($ch)、mysqli_close($conn) - 例外情况：部分扩展（如
pdo）在脚本结束时会尝试自动清理，但不可依赖——CLI 长任务或 Swoole Worker 中必然泄漏
gc_collect_cycles() 对 resource 无效，但可能间接影响资源关联对象
gc_collect_cycles() 只扫描 zval 中标记为 IS_TYPE_REFCOUNTED 的类型（array、object、string），resource 本身不在此列。但它可能触发持有 resource 的对象析构——前提是该对象已脱离所有外部引用，且其 __destruct() 方法里写了关闭逻辑。
- 风险点：若对象中保存了
curl句柄但__destruct()未调用curl_close()，GC 回收该对象后，句柄仍泄漏 - 陷阱场景：闭包捕获了 resource 变量，而该闭包又被对象属性持有 → 形成隐式循环，GC 能识别对象，但 resource 仍需手动关
- 验证方式：
echo gc_collect_cycles();返回值为 0 不代表没回收，只说明本轮没发现 zval 循环；要用lsof -p $(pgrep php)查 fd 数是否增长
memory_get_usage(true) 持续上涨时，优先排查 resource 泄漏而非 GC
当 memory_get_usage(true) 在多轮迭代中稳定上升（比如每轮 +1MB），而 gc_collect_cycles() 调用后无回落，大概率不是 GC 没生效，而是 resource 或扩展层堆内存泄漏。
- 常见肇事扩展：
ext/sockets（未socket_close()）、ext/curl（handle 复用异常）、ext/gd（imagedestroy()忘记调用） - 诊断步骤：先用
get_resources()列出当前所有 resource 类型及数量，对比前后差异；再用strace -e trace=close,socket,connect -p $(pgrep php)抓系统调用确认是否真关闭 - 注意：
WeakMap的键对象销毁后，其 value 若含 resource，不会自动清理——value 是普通 zval，但 resource 句柄本身不会被 WeakMap 管理
真正难缠的泄漏往往藏在 resource 和对象生命周期错位的地方：比如一个 SocketClient 对象在 __destruct() 里关 socket，但该对象被全局缓存数组长期持有，GC 根本不扫描它——这时候 gc_collect_cycles() 再勤快也没用，得从架构上切断持有关系或改用 WeakMap 存储弱引用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
