查清重复加载需分别检查CLI和FPM的全部配置路径：执行php --ini查CLI配置，宝塔中打开对应PHP版本的php.ini及/www/server/php/xx/etc/php.d/下所有.ini文件，同时检查www.conf中的php_admin_value[extension]，并排查/etc/php.d/和/usr/lib64/php/modules/等系统级残留。
查清哪些扩展正在被重复加载
“Module 'xxx' already loaded”不是扩展没装好，是 PHP 从多个配置位置同时读到了同一个 extension= 指令。宝塔的 PHP-FPM 和 CLI 配置完全独立，必须分别检查。
执行 php --ini 查看 CLI 加载的所有配置路径；再进宝塔 → 软件商店 → 对应 PHP 版本 → 设置 → 配置修改，打开 /www/server/php/xx/etc/php.ini（xx 是版本号，如 74、82）；还要检查 /www/server/php/xx/etc/php.d/ 下所有 .ini 文件。
- 逐个打开这些文件，搜索
extension=，特别留意swoole.so、opcache.so、redis.so等高频冲突项 - 宝塔旧版可能在
/etc/php.d/或/usr/lib64/php/modules/下留有残留配置，也得一并扫 - 注意：FPM 进程还会读取
www.conf里的php_admin_value[extension]，这个常被忽略
禁用非必要模块快速定位冲突源
别一上来就重装扩展，先做减法。把疑似冲突的模块临时注释掉，保留最简运行集（比如只留 mysqli、pdo），观察是否还报错。
例如 redis 扩展报错，就先在所有 php.ini 和 php.d/*.ini 中把 extension=redis.so 改成 ;extension=redis.so，然后重启对应 PHP-FPM 服务（不是重载）。
立即学习“PHP免费学习笔记（深入）”；
- 每次只禁用一个模块，改完立刻测试：CLI 执行
php -m | grep redis，Web 请求看是否 500 - 如果禁用
opcache.so后问题消失，但网站变慢，说明它和某个扩展（如 swoole、xdebug）存在 ABI 层级互斥 - 某些模块（如
bt_safe.so、swoole_loader_*.so）是宝塔或第三方插件自带，和官方扩展不兼容，优先禁用
确认扩展实际加载路径是否一致
PHP 显示已加载某扩展，不代表它真在跑你认为的那个版本。不同 PHP 版本的 extension_dir 不同，若 .so 文件放错目录，PHP 可能静默跳过或加载旧版。
执行 php-config --extension-dir，输出类似 /www/server/php/74/lib/php/extensions/no-debug-non-zts-20190902/；再用 php --ri redis 查看 “extension” 行，确认路径是否匹配。
- 不匹配？说明扩展是别人编译的，或者你手动拷贝错了目录。删掉错误路径下的
redis.so，重新用/www/server/php/74/bin/phpize编译 - 多个 PHP 版本共存时，
/www/server/php/74/lib/和/www/server/php/82/lib/必须严格隔离，不能共用一个.so - 宝塔软件商店安装的扩展，有时会硬写进系统级
/usr/lib64/php/modules/，导致所有 PHP 版本都去读——删掉它，改用面板内“安装扩展”功能
避免 opcache.jit 和协程扩展的隐性冲突
PHP 8.0+ 默认开启 opcache.jit=tracing，而 Swoole/OpenSwoole 的协程 Hook 与 JIT 编译器存在底层竞争，不报错但请求卡死、CPU 飙高。
这不是扩展没装对，是运行时行为冲突。必须显式关掉 JIT，哪怕只用到 Swoole\Coroutine::sleep()。
- 在目标 PHP 版本的
php.ini中，找到opcache.jit行，改为opcache.jit=off - 不要用
opcache.jit=1205或opcache.jit=1235，这些仍可能触发 Hook 冲突 - 改完后必须重启 PHP-FPM 进程（仅重载配置无效），因为 JIT 状态在进程启动时锁定
curl_init() 返回 false、json_encode() 丢字段、协程 sleep 不生效——它们往往不是扩展缺失，而是两个模块在共享内存或符号表里悄悄打架。动手前先 php --ri xxx 看真实加载路径，比重装十遍都管用。 
