php进程间不能直接用$var共享变量，因为每个请求运行在独立进程/线程中，全局变量、static、$_session等均不跨进程；需用shmop、redis等方案实现共享。
PHP 进程间共享变量为什么不能直接用 $var？
因为 PHP 默认每个请求启动独立进程（或线程），全局变量、静态属性、$_SESSION 都只在当前进程内有效，fork 出的子进程或 Nginx 下不同 worker 进程完全不共享内存。你改了 $counter，另一个进程根本看不到——这不是 bug，是设计使然。
常见错误现象：
– 用 pcntl_fork() 后父子进程各自修改同一变量，以为能“同步”
– 在 CLI 脚本里循环 sleep(1) 并期望另一个终端看到变量变化
– 把 static $cache = [] 当作跨进程缓存用
- 所有基于内存的变量（包括
static、global、对象属性）都不跨进程 -
$_SESSION依赖存储引擎（默认文件），但读写是串行的，高并发下易阻塞且不实时 - APCu 的
apcu_store()在 CLI 模式下默认不共享（需开启apc.enable_cli=1且同进程复用）
用 shmop 手动管理共享内存块
这是最接近“直接共享变量”的方式，但你要自己处理序列化、大小预估、锁和清理。适合小量、固定结构数据（如状态标志、计数器）。
使用场景：CLI 多进程任务协调（比如主进程分配任务 ID，子进程回写完成状态）
立即学习“PHP免费学习笔记（深入）”；
- 先用
shmop_open()创建/打开一块内存，key 必须是整数（如0x1234），不是字符串 - 写入前必须
serialize()，读取后unserialize()；原生不支持数组/对象自动序列化 - 内存大小要预估好，
shmop_write()超出会截断，没报错但数据损坏 - 进程退出时建议调用
shmop_delete()+shmop_close()，否则残留内存块会累积
示例（简单计数器）：
if (!$shm = shmop_open(0x1234, "c", 0644, 1024)) {
die("无法创建共享内存");
}
$data = ['count' => 1];
shmop_write($shm, serialize($data), 0);
// 其他进程读取：
$raw = shmop_read($shm, 0, 1024);
$data = unserialize($raw); // 注意检查是否 false
用 Redis 或 Memcached 做通用共享存储
90% 的真实需求该走这条路。它不共享“变量”，但共享“值”，且天然支持并发、过期、原子操作，比手动管内存靠谱得多。
性能影响：本地 Redis（127.0.0.1:6379）单次 set/get 约 0.1–0.5ms，远低于文件锁或数据库查询；网络延迟可控，别用公网 Redis。
- 不要用
set('counter', $val)直接覆盖——竞态条件会导致丢失更新 - 计数类用
incrby('counter', 1)，状态类用setex('status', 300, 'running') - 避免大对象（>100KB）存 Redis，序列化/传输开销陡增；优先拆成小字段
- PHP 连接 Redis 推荐
phpredis扩展（非predis纯 PHP 库），性能差 3–5 倍
为什么别碰 sysvshm 和 apcu 跨进程共享？
sysvshm 是老式 System V 共享内存封装，API 更晦涩，权限管理复杂，Linux 上常被禁用；apcu 的共享仅限于同一个 PHP-FPM worker pool 内（即同个 FPM 子进程多次请求），重启 FPM 或换 worker 就失效。
容易踩的坑：
-
apcu_store('key', $val)在 CLI 脚本里设的值，Web 请求完全读不到（除非明确启用apc.enable_cli=1且共用同一 APCu 实例） -
sysvshm的 key 用ftok(__FILE__, 'a')生成，但文件路径稍有不同就得到不同 key，调试极难定位 - 两者都不提供 TTL、CAS（check-and-set）、管道等现代缓存必需能力
真正需要低延迟共享且能接受复杂度的场景极少，多数时候是误判了问题本质——你要的往往不是“共享变量”，而是“可靠的状态协同”。
