本质是文件权限、用户归属或selinux策略导致swoole.so无法被php-fpm读取，需依次检查并修复so文件权限（chmod 644）、归属（chown www:www）、selinux上下文（semanage+restorecon），并确保cli与fpm加载同一路径的so文件。
宝塔面板安装Swoole扩展时提示“Permission denied”“cannot open shared object file”或“failed to load extension”，本质是文件权限、用户归属或SELinux策略导致swoole.so无法被PHP-FPM进程读取，不是版本不匹配也不是网络问题。
确认swoole.so文件权限是否被拒绝
执行命令查看so文件实际权限：ls -l /www/server/php/81/lib/php/extensions/no-debug-non-zts-20200930/swoole.so。
如果输出中权限位不含【r】（如显示----------或-w-------），说明PHP进程根本无权读取该文件——这正是Permission denied的根源。
直接修复权限：运行chmod 644 /www/server/php/81/lib/php/extensions/no-debug-non-zts-20200930/swoole.so。
注意：不能用755，PHP扩展要求so文件不可执行，否则部分安全加固环境会拒绝加载。
检查so文件归属用户是否为root而PHP-FPM以www用户运行
执行ps aux | grep php-fpm，确认主进程启动用户（通常是www）。
再执行ls -l /www/server/php/81/lib/php/extensions/no-debug-non-zts-20200930/swoole.so，若Owner显示为root:root，而PHP-FPM以www用户运行，则因Linux用户隔离机制导致无法加载。
修正归属：运行chown www:www /www/server/php/81/lib/php/extensions/no-debug-non-zts-20200930/swoole.so。
这一步必须做，否则即使权限设为644，www用户仍因非Owner身份被系统限制读取——尤其在启用了strict mode的CentOS/RHEL上表现明显。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
SELinux阻止PHP-FPM访问扩展目录（仅限CentOS/RHEL）
先判断是否启用SELinux：sestatus。若Status为enabled，则继续。
临时放行测试：运行setenforce 0，然后重启PHP服务并验证php --ri swoole是否成功。
若此时正常，说明SELinux是真凶。永久修复需打标签：semanage fcontext -a -t httpd_exec_t "/www/server/php/81/lib/php/extensions/no-debug-non-zts-20200930(/.*)?" → restorecon -Rv /www/server/php/81/lib/php/extensions/no-debug-non-zts-20200930/。
【关键点】不执行restorecon，仅打标签无效；且路径末尾的(/.*)?不能省略，否则子目录不继承上下文。
验证CLI与FPM是否共用同一份so文件且权限一致
第一步：分别查CLI和FPM加载的php.ini路径：/www/server/php/81/bin/php --ini 和 grep -A1 "php_admin_value.*extension" /www/server/php/81/etc/php-fpm.d/www.conf。
第二步：确认两个环境指向的swoole.so物理路径完全相同（不是软链接不同源）。
第三步：对两个路径都执行一次ls -l比对权限与归属——常见陷阱是只改了CLI对应路径的so权限，却漏掉FPM实际读取的那个路径。
例如FPM配置里写的是extension=/www/server/php/81/lib/php/extensions/no-debug-non-zts-20200930/swoole.so，但CLI的php.ini里写的是extension=swoole.so（依赖extension_dir），二者最终可能指向不同目录。
