hyperf 不靠协程共享内存解决多进程冗余，而是废除多进程模型，采用单进程+多协程架构，启动时仅加载一次代码与依赖，所有协程复用同一内存空间，从而降低内存占用80%；协程仅在单个worker进程内调度，不跨进程，所谓“共享内存”实为协程间内存复用，非进程间共享。
Hyperf 不能靠“协程共享内存”来解决多进程内存冗余——这个说法本身混淆了进程模型和协程模型的根本差异。协程不跨进程，它只在**单个 Swoole Worker 进程内调度**；而“多进程内存冗余”问题，恰恰来自传统 PHP-FPM 的多进程架构（每个请求 fork 一个新进程，各自加载完整代码、类、配置），Hyperf 的解法是**直接废掉多进程模型**，改用常驻内存的单进程+多协程架构。
所以不是“用协程去共享已有多个进程的内存”，而是：**启动时只加载一次代码和依赖，所有协程复用同一份内存空间**。这才是内存占用下降 80% 的真实原因。
为什么协程不等于进程间共享内存
协程（coroutine）是用户态轻量级执行单元，在同一个 OS 进程里运行，共享该进程的堆、全局符号表、已加载的类定义等——这叫“协程间内存复用”，不是“多进程间共享”。
而 shared_memory、mmap、shm_open 等机制，才是真正的跨进程内存共享，它们需要显式创建命名对象、映射地址、同步访问，且与 PHP 协程无关。
Hyperf 实际怎么降低内存占用
-
Hyperf启动后，所有协程共用一份已解析的类结构、Composer autoloader 映射、配置数组、路由表等——这些在 PHP-FPM 下每进程重复加载，浪费巨大 - 连接池（如
Hyperf\Database\Connection、Hyperf\Redis\Redis）按 Worker 进程维度初始化，每个协程从池中借用连接，而非每次 new 一个新连接对象 - 框架组件（如 AOP 切面、事件监听器、中间件实例）在容器中单例化，协程只读取引用，不复制对象
- 注意：
Co\Context和RequestContext是协程隔离的，它们写入的数据不会污染其他协程，但底层仍复用同一片 PHP 堆内存——这是安全复用，不是数据共享
误用 CoroutineMemoryDriver 当作“跨协程缓存”会出事
有人看到 CoroutineMemoryDriver 名字里有 “Memory”，就以为能当进程级缓存用——完全错误。
它只绑定当前协程生命周期，请求结束自动销毁，根本无法跨协程读取。
若你在多个协程里反复调用 cache()->driver('co')->set('key', $val)，每个协程都存一份独立副本，不仅没节省内存，反而因重复构造导致更高开销。
真正需要跨协程/跨请求共享的数据，必须走 Redis 或 Swoole\Table，而不是协程内存驱动。
Worker 进程数设置不当反而放大内存压力
虽然协程省内存，但 Hyperf 默认按 CPU 核数启动 Worker 进程（例如 8 核 → 8 个 Worker）。每个 Worker 是独立 OS 进程，有自己的内存空间：
- 每个 Worker 都会加载一遍框架代码、配置、连接池（哪怕池里只放 1 个连接）
- 如果设了
worker_num = 32，即使并发不高，也会预先占用 32 倍的静态内存 - 推荐值：
worker_num = cpu_count（超线程也只算物理核），高 IO 场景可适度 +1～2，但绝不盲目堆数量
