直接提高cli的memory_limit需在命令前加php -d memory_limit=-1参数，因phpize和pecl受cli sapi内存限制约束，改php.ini无效；make失败则属系统依赖缺失，非内存问题。
直接提高 CLI 的 memory_limit 就能绕过绝大多数编译失败，但必须用对方式——改 php.ini 不起作用，得在命令前加参数。
phpize 或 pecl 运行时爆内存，本质是 PHP CLI 自身内存限制太低
phpize 和 pecl 都是 PHP 脚本封装的命令，内部会加载 config.m4、解析扩展结构、生成 configure 脚本等，全程受 CLI SAPI 的 memory_limit 约束。即使你把 php.ini 里设成 2G，若没指定 CLI 模式生效，它仍可能卡在默认的 128M。
- 临时解决：所有涉及 phpize 或 pecl 的命令前，统一加
php -d memory_limit=-1，例如：php -d memory_limit=-1 /www/server/php/80/bin/phpize - pecl 安装也一样：
php -d memory_limit=-1 pecl install swoole - 不建议全局改 CLI 的 php.ini（比如
/www/server/php/80/bin/php.ini）里的memory_limit，容易掩盖真实泄漏问题；但若频繁装扩展，可临时注释掉该行，让其 fallback 到无限制
make 阶段失败不是内存问题，而是 C 层依赖或头文件缺失
如果 phpize 和 ./configure 成功了，但 make 报错（比如 fatal error: openssl/ssl.h: No such file 或 undefined reference to 'SSL_CTX_new'），这和 PHP 内存无关，是系统级构建环境缺东西。
- Ubuntu/Debian 必装：
libssl-dev、libcurl4-openssl-dev、libc-ares-dev、libbrotli-dev - CentOS/RHEL 必装：
openssl-devel、libcurl-devel、c-ares-devel、brotli-devel -
libtool、autoconf、automake是 make 前置依赖，CentOS 用yum install libtool autoconf automake，Ubuntu 用apt install libtool autoconf automake - PHP 8.5+ 编译 Swoole 还要显式加
--enable-coroutine，否则Swoole\Coroutine::sleep()直接报not available
验证是否真装上了，别信 php -m | grep swoole
这个命令只说明模块名在列表里，不等于扩展已正确加载或 ABI 匹配。很多“装了但用不了”的情况，其实是 swoole.so 被编译进了错误路径，或只配了 FPM 的 php.ini 没配 CLI 的。
- 可靠验证命令是：
/www/server/php/80/bin/php --ri swoole（路径必须和你实际 PHP 子目录一致） - 输出里必须有
Version和compiled行，且两者的 PHP 版本号要完全一致，比如都是8.0.30 - 如果报
Extension 'swoole' not present，90% 是漏改了 CLI 的配置文件：/www/server/php/80/bin/php.ini（注意不是/etc/php.ini或/www/server/php/80/etc/php.ini） - 改完后必须「重启 PHP」服务（宝塔点「重启」），不能只「重载」
最常被忽略的是：CLI 和 FPM 加载的是两套完全独立的配置，哪怕只差一个字符的路径，或者少加一次 extension=swoole.so，都会导致某一边失效。尤其在跑 php artisan swoole:http start 这类命令时，崩就崩在 CLI 环境里。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
