hyperf 在 arm 架构上需针对性编译 swoole 并配置：启用 neon/lse、禁用 opcache.file_cache、设 swoole_hook_all、优先使用 swoole/json 且不带 json_throw_on_error 标志，worker_num 设为物理核心数、max_coroutine ≤8000。
Hyperf 在 ARM 架构（如 Apple M1/M2/M3、AWS Graviton、飞腾、鲲鹏）上默认能跑，但若未针对性编译 Swoole，会丢失 NEON 指令加速、未启用 LSE 原子指令、协程切换和 JSON 编解码性能明显低于 x86_64 同配置——这不是 Hyperf 的问题，而是 Swoole 底层 C 代码未对 ARM 进行向量化与内存模型适配。
编译 Swoole 时必须启用 SWOOLE_USE_NEON 和 SWOOLE_USE_LSE
ARM64 上的浮点与 SIMD 加速（如 base64、JSON 数值解析、CRC32C 校验）严重依赖 NEON；而高并发下的原子操作（sw_atomic_t、协程栈切换标记）在没有 LSE（Large System Extension）支持时会回退到较慢的 LL/SC 循环。不显式开启，cmake 默认关闭。
- 编译前确认系统已安装
arm-linux-gnueabihf-gcc或aarch64-linux-gnu-gcc（交叉编译）或本地gcc（原生 ARM 编译） - 进入 Swoole 源码目录后执行：
cmake -D SWOOLE_USE_NEON=ON -D SWOOLE_USE_LSE=ON -D SWOOLE_STATIC_LIBGCC=ON .
-
SWOOLE_STATIC_LIBGCC=ON避免运行时链接 glibc 版本冲突（ARM Linux 发行版间 libc 差异大） - 编译完成后，用
php --ri swoole | grep -E "(neon|lse|atomic)"验证是否生效，应看到neon support => enabled和lse support => enabled
php.ini 中禁用 opcache.file_cache 并调低 opcache.max_accelerated_files
ARM 设备（尤其 Mac Silicon）的文件系统缓存策略与 x86 不同，opcache.file_cache 在 APFS 上易引发 mmap 冲突，导致 worker 进程启动卡顿或偶发 segfault；同时 max_accelerated_files 过高（如默认 10000）会使 opcache hash 表在 ARM 的 L1/L2 缓存中频繁 miss，反而拖慢类加载。
- 在
php.ini中设为：opcache.file_cache=""<br>opcache.max_accelerated_files=4096
- Hyperf 启动时若发现
file_cache非空，会自动 fallback 到共享内存模式，但 ARM 上 shm 大小限制更严（/proc/sys/kernel/shmall），不如直接关掉 - 验证：启动后执行
php -r "var_dump(opcache_get_status()['opcache_statistics']['max_cached_keys']);"，输出应接近 4096 而非 10000+
Hyperf 配置中关闭 enable_coroutine 的自动钩子，改用显式 SWOOLE_HOOK_ALL
ARM 下 Swoole 的自动钩子（SWOOLE_HOOK_DEFAULT）存在 syscall 补丁不全问题，尤其在 getaddrinfo 和 epoll_wait 之间有竞态，表现为 DNS 解析超时或连接池连接复用失败；而 SWOOLE_HOOK_ALL 强制重写所有 I/O 函数入口，虽略增开销，但在 ARM 上稳定性提升显著。
- 在
.env中设置：SWOOLE_HOOK_FLAGS=SWOOLE_HOOK_ALL
- 不要在
config/autoload/server.php的settings里设enable_coroutine => true—— 它只控制协程调度器开关，不等价于钩子启用 - 验证：请求一个带外网 HTTP 调用的接口，用
strace -p $(pgrep -f "hyperf start") -e trace=connect,sendto,recvfrom观察是否仍出现原生connect系统调用（有则钩子未生效）
JSON 编解码必须启用 swoole/json 扩展并禁用 json_decode 的 JSON_THROW_ON_ERROR
ARM 上原生 json_decode 的浮点解析路径未优化，比 x86 慢约 40%；而 swoole/json 使用 NEON 向量化解析整数和字符串，在 M1 上实测快 2.7 倍。但若代码中用了 JSON_THROW_ON_ERROR，会触发 PHP 异常机制，绕过 swoole/json 的 fast path。
- 确认扩展已加载：
php --ri swoole | grep json应显示json => enabled - Hyperf 会自动优先使用
swoole/json，但前提是调用不带标志位：// ✅ 正确<br>json_decode($json);<br>// ❌ 错误（强制走原生）<br>json_decode($json, flags: JSON_THROW_ON_ERROR);
- 生产环境统一用
Hyperf\Utils\Json::decode()，它内部已做兼容判断且不传 flags
ARM 上的性能拐点不在 CPU 核心数，而在内存带宽和 cache line 对齐——worker_num 设为物理核心数（非逻辑线程数），max_coroutine 控制在 8000 以内，避免 L3 cache thrashing；任何试图“照搬 x86 参数”的做法，在 Apple Silicon 或 Graviton 实例上都会迅速暴露底层差异。
