--enable-sysvshm是PHP编译时启用System V共享内存支持的必要参数，属内置扩展，无需php.ini加载；若php -m无输出或shmop_open返回false，通常因编译未启用该选项或IPC权限/资源冲突导致。
phpenv 本身不负责编译或启用扩展，它只是管理多个 PHP 版本的「外壳工具」。真正决定 sysvshm 是否可用的，是每个 PHP 版本在编译时是否启用了 --enable-sysvshm，以及运行时是否加载了对应模块。
你用 phpenv 切换到某个 PHP 版本后，php -m | grep shm 返回空，基本可以断定：这个版本编译时没开 sysvshm，或者虽编译了但没在 php.ini 中启用。
编译 PHP 时必须加 --enable-sysvshm
phpenv 安装新版本 PHP（比如通过 php-build 插件）时，默认配置通常不包含 sysvshm。必须显式添加：
编译前确认系统已安装 System V 共享内存支持（Linux 下一般自带，无需额外装包）
立即学习“PHP免费学习笔记（深入）”；
修改 ~/.phpenv/plugins/php-build/share/php-build/definitions/7.4.33（或其他你要装的版本定义文件），在 configure_options 里追加：
--enable-sysvshm \ --enable-sysvsem \ --enable-sysvmsg
这三项常一起启用，因为它们同属 System V IPC 套件。缺一不可——比如只开 sysvshm 但没开 sysvsem，ftok() 可能失败或返回无效 key。
然后执行：
-
phpenv install 7.4.33（触发重新编译） phpenv global 7.4.33-
php -m | grep sysv应该看到sysvshm、sysvsem、sysvmsg
php.ini 不需要手动加 extension=sysvshm.so
sysvshm 是 PHP 的「内置扩展（built-in）」，不是动态加载的 .so 模块。只要编译时加了 --enable-sysvshm，它就直接链接进 php 二进制里，不需要、也不能在 php.ini 中写 extension= 行。
如果你强行加了：
extension=sysvshm.so
PHP 启动时会报错：PHP Warning: Unable to load dynamic library 'sysvshm.so'——因为根本不存在这个独立 so 文件。
验证方式：
-
php --ri sysvshm（有输出说明已启用） -
php -r "var_dump(function_exists('shmop_open'));"→bool(true)
共享内存段权限与 sysvshm.init_mem 配置无效
php.ini 里有个 sysvshm.init_mem 配置项，文档写默认值是 10000，但实际在 PHP 7.2+ 中完全被忽略——它只在极老版本（PHP 5.x）中影响 shmop_open() 默认行为，现在所有大小都由你代码里传入的第 4 个参数控制。
更关键的是权限问题：
-
shmop_open($key, 'c', 0600, 1024)中的0600是 Unix 权限掩码，不是 umask - 若用
0644，其他用户可能读取你的共享内存（尤其在多租户环境） - 若用
0600，但 PHP 进程以不同用户身份运行（如 FPM worker vs CLI），shmop_open()会失败并返回false
调试建议：
- 用
ipcs -m查看当前系统共享内存段，确认是否残留旧段（避免 key 冲突） - 用
ipcs -q和ipcs -s顺手检查消息队列和信号量，System V IPC 资源容易泄漏
sysvshm 的坑不在调用函数本身，而在编译开关、IPC 资源生命周期管理和跨进程权限对齐。很多人卡在「函数存在但 shmop_open 返回 false」，其实八成是编译漏了 --enable-sysvshm，或 key 生成后被其他进程占用了。
