答案是权限、路径、编译器版本及配置不匹配导致的典型环境问题：需确认PHP extension_dir可写、避免sudo pecl、改用源码编译并指定正确phpize/php-config，GCC≥7.0，正确配置php.ini且区分CLI/FPM，绑定低端端口需setcap或反代。
pecl install swoole 提示“Cannot install, php_dir ... is not writeable”
这是 macOS 或 Linux 上最典型的权限卡点：PECL 默认试图把扩展写进系统级目录（比如 /usr/local/lib/php/extensions），但当前用户没写权限。它不是 swoole 本身的问题，而是 PECL 的安装路径策略和你的用户权限不匹配。
- 别直接
sudo pecl install swoole—— 这会让扩展装进 root 权限路径，后续 PHP-FPM 或 CLI 调用时可能因用户隔离导致“找不到扩展” - 先查清你实际要用的 PHP 是哪个：
which php和php -r "echo ini_get('extension_dir');"，确认extension_dir路径是否可写（比如宝塔下通常是/www/server/php/80/lib/php/extensions/no-debug-non-zts-20200930） - 更稳妥的做法是跳过 PECL，改用源码编译：下载对应版本的
swoole-src，在源码根目录执行/path/to/phpize（务必用你目标 PHP 对应的 phpize），再./configure --with-php-config=/path/to/php-config，最后make && sudo make install
make 报错 “error: ‘optional’ in namespace ‘std’ does not name a template type”
这不是配置错误，是 GCC 版本太老——Swoole 4.8+ 强制依赖 C++17，而 CentOS 7 默认 gcc 4.8.5、Ubuntu 16.04 默认 gcc 5.4 根本不认识 std::optional。
- 运行
gcc --version确认版本；低于 7.0 基本不用试，直接升级 - CentOS 7 推荐用
devtoolset-9（比手动编译 GCC 省事）：yum install centos-release-scl && yum install devtoolset-9，然后scl enable devtoolset-9 bash再编译 - Ubuntu 用户可加源：
apt-add-repository ppa:ubuntu-toolchain-r/test && apt update && apt install gcc-9 g++-9，再用update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-9 90切换 - 注意：升级 GCC 后，必须重新运行
phpize（不是重装 PHP），否则 configure 仍会调旧编译器
装完 swoole.so，php -m 看不到或报 Class 'swoole_http_server' not found
扩展文件确实生成了，但 PHP 没加载成功，常见于路径错配或配置残留。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 检查
php.ini路径是否正确：php --ini输出的 Loaded Configuration File，别只改 CLI 的，漏掉 FPM 的php.ini（宝塔里 CLI 和 FPM 配置常分开放） -
extension=swoole.so这行必须写在php.ini末尾，且不能有空格或中文字符；如果用了extension_dir自定义路径，确保swoole.so真的在那个目录下 - 宝塔用户特别注意：FPM 还可能从
www.conf里通过php_admin_value[extension]加载，这里重复写swoole.so会导致Module 'swoole' already loaded错误，反而让类不可见 - 验证是否真加载：
php --ri swoole，有输出才说明扩展就位；若报“no such file”，说明路径或权限仍有问题
Linux 下 systemd 自启 Swoole 服务提示 Permission denied 绑定 80/443 端口
非 root 用户无法监听 1024 以下端口，但直接用 root 启动又违背安全原则——这不是 swoole 的 bug，是 Linux 的 capability 机制在起作用。
- 别改
CapabilityBoundingSet或开ambient，太重；推荐用setcap授予 PHP 解释器绑定低端端口的能力：sudo setcap 'cap_net_bind_service=+ep' /usr/bin/php（路径以which php为准） - 如果用的是宝塔或自建 systemd unit，确保 service 文件里
User=设为实际运行用户（如www-data），且去掉PermissionsStartOnly=true类似干扰项 - 更通用的方案是反向代理：Nginx 监听 80/443，转发到 Swoole 的 9501 等高端口，彻底避开权限问题，也更符合生产部署习惯
真正卡住人的往往不是编译命令本身，而是环境里那些“默认值”——PHP 的 extension_dir、系统的 gcc 版本、systemd 的 user 配置、甚至宝塔里 CLI 和 FPM 的两个 php.ini。盯住一个点猛试不如先跑一遍 php -i | grep -E "(extension_dir|configure)"; gcc --version; ls -l $(php-config --extension-dir)，信息齐了，路就清楚了。
