php 7.4 无原生“共享空间”，所谓共享内存实为 apcu、opcache、swoole\table 等扩展实现；清空需调用对应扩展的清理接口（如 apcu_clear_cache、opcache_reset、$table->destroy），unset 和 gc_collect_cycles 对其无效。
PHP 7.4 没有“共享空间”这个原生概念——你遇到的大概率是 APCu、OPcache、Swoole\Table、Redis 或自定义的全局静态缓存（如 static $cache = []），它们常被误称为“共享空间”。真正跨请求/进程共享内存的，只有扩展层实现的机制，PHP 自身的变量作用域无法跨请求持久化。
APCu 缓存怎么清空
APCu 是用户态内存缓存，数据驻留在 PHP 进程的共享内存段中。它不随脚本结束自动释放，必须显式清理：
-
apcu_clear_cache()清空全部用户缓存；加参数'user'更明确：apcu_clear_cache('user') - 按前缀清理（PHP 7.4+ 支持）：
apcu_delete(preg_grep('/^myapp_/', apcu_get_keys())) - 单键删除更安全：
apcu_delete('myapp_config')，避免误清其他模块缓存 - 注意：CLI 模式下 APCu 默认禁用（
apc.enable_cli=0），若启用需确认配置生效
OPcache 内存怎么重置
OPcache 缓存的是已编译的 opcode，占用的是 Zend 引擎管理的共享内存池，不是 PHP 变量内存。它不响应 unset() 或 gc_collect_cycles()：
- 重启 PHP-FPM 或 Apache 才能彻底释放 OPcache 共享内存段
- 运行时可用
opcache_reset()重载脚本缓存，但不会归还已分配的共享内存页（只是标记为可复用） - 调优关键配置：
opcache.memory_consumption=128（别设过大），opcache.max_accelerated_files匹配实际文件数，避免哈希表膨胀 - 误判常见点：
memory_get_usage()不包含 OPcache 占用，它只统计当前脚本堆内存
Swoole\Table 或全局静态数组泄漏
这类结构在常驻进程中长期持有引用，是 PHP 7.4 下最典型的“伪共享内存泄漏”：
-
Swoole\Table必须手动$table->destroy()，否则内存永不释放（底层调用shmdt+shmctl） - 静态属性（如
class Cache { public static $data = [];）需主动清空：self::$data = [];或unset(self::$data); - 禁止在循环中无限制追加：
static $log[] = $item;—— 改用固定大小环形缓冲或定期array_shift() - CLI 常驻进程里，
gc_collect_cycles()对静态变量无效，必须靠代码逻辑清理
为什么 unset() 和 gc_collect_cycles() 都没用
因为这些操作只影响当前脚本堆内存（Zend heap），对扩展申请的共享内存（shmem）、mmap 映射区或 C 层 malloc 分配完全无感知：
-
unset($var)只减少 PHP 变量的引用计数，若$var是APCu键名或Swoole\Table句柄，它不触碰底层共享段 -
gc_collect_cycles()只扫描 PHP 的 zval 循环引用，不扫描 APCu 的 hash 表节点或 Swoole 的共享内存块 - 真正的释放动作由扩展自己控制：比如
apcu_clear_cache()调用apc_cache_clear()C 函数，遍历并efree()每个缓存项 - 最容易忽略的一点：某些扩展（如旧版
swoole）在析构时未正确调用zend_hash_destroy()，导致 HashTable 元素残留——此时只能升级扩展或换方案
共享内存的释放权不在 PHP 脚本手里，而在具体扩展的 C 实现中。看清你用的是哪个扩展，查它的文档里明确写的清理接口，比盲目调用 unset 或 gc 有效得多。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
