Swoole模块未被PHP实际加载的根源是CLI与FPM配置分离及编译参数缺失。需确认php.ini路径、extension_dir与swoole.so位置一致，并检查coroutine/openssl/http2是否启用，最后用脚本验证核心功能。
php --ri swoole 报“not found”但 extension 已加
这说明 Swoole 模块没被 PHP 实际加载，不是“装没装上”的问题，而是“PHP 找不着它”。常见原因有两个：php.ini 改错了文件 或 swoole.so 路径不对。
- 执行
php --ini查看 CLI 加载的配置路径，确认你编辑的是/www/server/php/80/bin/php.ini（宝塔）或C:\phpEnv\php\php-8.0.30\php.ini（phpEnv），不是 FPM 用的那个 - 执行
php -r "echo ini_get('extension_dir');"，输出目录要和make install后提示的路径一致，比如/www/server/php/80/lib/php/extensions/no-debug-non-zts-20200930/ - 检查该目录下是否存在
swoole.so（Linux/macOS）或php_swoole.dll（Windows），文件名必须完全匹配extension=后写的值
php -m 显示 swoole 但协程/HTTP Server 用不了
模块加载成功 ≠ 功能可用。Swoole 的部分能力（如 Swoole\Http\Server、co::sleep()）依赖编译时启用对应参数，运行时缺了就直接报错 “Call to undefined function”。
- 运行
php --ri swoole，重点看输出里有没有openssl => enabled、http2 => enabled、coroutine => enabled这几行 - 如果缺
coroutine，源码编译时漏了--enable-coroutine；缺openssl就会无法启动 HTTPS 服务，连new Swoole\Http\Server都失败 - PECL 安装默认可能不启这些，建议用
pecl install swoole后手动补参数重装，或改用源码编译确保可控
Web 页面 phpinfo() 有 swoole，命令行 php --ri swoole 却报错
这是典型的 CLI 和 FPM 配置分离导致的。宝塔、phpEnv、Wamp 等环境都把两者配置文件分开管理，改一个不等于改另一个。
- FPM（Web）加载的是
/www/server/php/80/etc/php.ini（宝塔）或C:\phpStudy\php\php-8.0.30\php.ini（phpStudy） - CLI（命令行）加载的是
/www/server/php/80/bin/php.ini或php --ini输出的路径 - 两个文件末尾都要加
extension=swoole.so（Linux）或extension=php_swoole.dll（Windows），不能只改一个 - 改完后，宝塔点「重启 PHP」，phpStudy 点「重启服务」，CLI 不需重启但要用
/www/server/php/80/bin/php --ri swoole单独验证
写个最简脚本测试真实可用性
光看列表和 phpinfo 不够，得跑起来。以下三行代码能暴露绝大多数隐藏问题：
立即学习“PHP免费学习笔记（深入）”；
<?php
var_dump(class_exists('Swoole\Http\Server')); // false = openssl/http2 没开或版本太低
var_dump(function_exists('co::sleep')); // false = coroutine 未启用
(new Swoole\Http\Server('127.0.0.1', 9501))->start(); // 直接抛异常？说明底层功能缺失或端口被占
注意：最后一行会阻塞，测试完 Ctrl+C 中断即可。只要前两行返回 true，基本可判定核心能力就绪；第三行能不报错启动，说明环境已真正可用。
最容易被忽略的是：CLI 和 FPM 的 php.ini 是两套，extension_dir 路径和 swoole.so 文件位置必须严格对应，且所有依赖参数（--enable-openssl 等）必须在编译时一次性带上——少一个，功能就残废一半。
