必须关闭swoole.use_shortname=off，否则go()等短函数会污染zend内存分配器，引发zend mm unknown error崩溃；需同时配置cli与fpm的php.ini并验证function_exists('go')返回false。
Zend MM unknown error 本质不是 Hyperf 或 Swoole 的错误，而是 PHP 内存管理器（Zend Memory Manager）在启用 swoole.use_shortname = On 时被破坏导致的崩溃。必须关闭短名称，否则启动必然失败或随机 segfault。
为什么关闭 swoole.use_shortname 是硬性前提
Hyperf（以及 Swoole 官方）明确要求禁用 Swoole 短函数名。一旦开启，go()、chan()、mutex() 这类全局函数会污染 PHP 的 Zend 内存分配器，导致后续协程或扩展初始化时触发 Zend MM unknown error —— 这个错误不报具体行号，只 crash，极难定位。
- 该设置必须同时作用于 CLI 和 FPM（如果共用 PHP 配置），但 Hyperf 启动走的是 CLI，所以优先确认
php -i | grep "swoole.use_shortname"输出为Off - 常见陷阱：宝塔面板里勾选了 Swoole 扩展，但没手动关掉 Short Name；或改了
php.ini却忘了重启 PHP-FPM，而 CLI 没读这个 ini（实际读的是php-cli.ini） - 验证方式：执行
php -r "var_dump(function_exists('go'));"，返回bool(false)才算生效
如何确认并修复 swoole.use_shortname 配置
别只改一个配置文件。CLI 和 Web 环境可能加载不同 ini，Hyperf 启动失败往往是因为 CLI 没关干净。
- 查当前 CLI 实际生效的配置路径：
php --ini，重点关注Loaded Configuration File和Scan for additional .ini files in - 在对应
php.ini或php-cli.ini末尾添加：swoole.use_shortname = Off（注意是= Off，不是= 'Off'或= 0） - 如果使用宝塔，进「PHP 设置 → 禁用函数」页面，确保
putenv,pcntl_alarm,pcntl_fork...等未误删，但重点看「安装扩展」页里 Swoole 行右侧是否显示 “Short Name: Off” - 改完后务必运行
php -m | grep swoole确认扩展已加载，再执行php -i | grep "swoole.use_shortname"确认值为 Off
启动仍报 Zend MM unknown error？检查这些隐藏冲突点
即使短名称已关，某些扩展或环境变量仍会间接触发相同错误表现。
- 其他协程扩展共存：比如同时启用了
ext-uv或旧版ext-swoole（非官方源码编译版），它们可能自带短名逻辑，卸载冲突扩展再试 - SWOOLE_HOOK flags 设置不当：若在
server.php中手动设置了'options' => ['hook_flags' => SWOOLE_HOOK_ALL]，而底层 Swoole 版本不支持全部 hook，也可能引发内存管理器错乱，可先注释掉该行测试 - PHP 编译参数问题：某些定制 PHP（如 CloudLinux、某些 Docker 镜像）启用了
--enable-maintainer-zts但未配对启用线程安全扩展，此时即使关 shortname 也容易崩，建议换用官方 PHP + Swoole 组合 - 环境变量干扰：临时清空再启动：
env -i PATH=$PATH php bin/hyperf.php start，排除LD_PRELOAD或其他注入式内存 hook 工具影响
真正麻烦的不是找不到配置项，而是你以为关了，其实 CLI 没读到；或者你关了，但另一个扩展悄悄把它又开了。每次改完，务必用 php -r 直接测函数是否存在，比看日志更可靠。
