tp6.0内存占用高主因是变量生命周期管理不当，如循环/中间件/查询结果中unset不及时导致zval引用计数不归零；unset彻底删除变量名，$var=null仅置空指针；需确保引用计数为0、无循环引用且gc运行才能真正释放内存。
unset() 在老 CMS 里基本没用，除非你先断引用
PHPCMS、Destoon 这类 PHP 7.4 时代的 CMS，普遍在模板层或控制器里反复 include、require 大量文件，还喜欢把数据库结果集（如 $data = $db->select(...)）直接塞进全局数组或静态属性。这时候单靠 unset($data) 几乎不降内存——因为变量名虽没了，但底层 zval 还被其他地方（比如模板引擎缓存、插件钩子、全局 $GLOBALS）强引用着。
实操建议：
- 查清变量是否被多个地方引用：用
xdebug_debug_zval('var_name')（需开启 Xdebug）看 refcount 和 is_ref；没 Xdebug 就临时加var_dump($GLOBALS)搜关键词 - 对模板中传入的大数组，别只在模板末尾
unset($list)，得在include前就清理掉上一轮残留的同名变量 - CMS 插件常通过
hook_add('footer', function(){ ... })注册回调，这些闭包会隐式捕获外部变量——要释放就得先清空 hook 队列，再unset
gc_collect_cycles() 必须手动调，且得在合适时机
PHP 7.4 的 GC 对循环引用支持比早期版本强，但默认触发阈值高（根缓冲区满 10000 条才扫），而老 CMS 的模块加载逻辑常导致对象间形成“父模块 → 子插件 → 回调闭包 → 父模块”的闭环。等脚本自然结束才回收，中间内存就堆上去了。
实操建议：
- 在关键分界点调用：
gc_collect_cycles()放在列表页渲染完、准备跳转前；或导出 CSV 写完文件后、关闭句柄前 - 别在循环体内每轮都调——它本身有开销，每 50–100 次迭代调一次更稳
- 验证是否生效：用
memory_get_usage(true)（注意是true！否则看到的是虚假“已用”值）对比调用前后
资源型属性必须显式关，不能只靠 unset
老 CMS 里常见 fopen() 读配置、mysqli::query() 执行 SQL、curl_init() 调外部接口。这些返回的资源（resource）不释放，内存就一直挂着，哪怕对象本身被 unset 了。
实操建议：
- 查代码里所有
fopen、curl_init、mysqli_connect的调用点，在对应位置补上fclose、curl_close、mysqli_close - 数据库操作别用
mysql_query（已废弃），改用mysqli或PDO，并确保$stmt->close()或$pdo = null显式切断 - 如果用了 PHPCMS 自带的
cache_read()，它内部可能用flock+fopen，得确认其cache_write()是否配对调用了fclose
大数组赋 null 比 unset 更可靠，但要注意作用域
在 PHPCMS 的 phpcms/modules/content/index.php 这类文件里，经常看到 $datas = $this->db->fetch_all($sql) 后直接传给模板。这时 $datas = null 比 unset($datas) 更有效——前者让所有指向该 zval 的变量（包括模板里 $data 的副本）立刻失去数据源；后者只删当前作用域的符号表条目。
实操建议：
- 对万级以上的
fetch_all结果，写成$datas = null;，而不是unset($datas) - 别在函数里对全局大数组做
$GLOBALS['big_list'] = null——这会污染全局，应改在定义它的文件末尾统一置空 - 检查 CMS 的缓存类（如
pc_base::load_sys_class('cache')），它可能把数据存在静态属性里，得调用clear_cache()或直接self::$_instance = null
unset 了，其实只是把钥匙扔了，门还开着。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
