不能直接改全局autoloader，因报错多源于命名空间冲突、类重复加载或Composer autoload机制破坏；手动require与Composer自动加载同一类会触发“Cannot declare class”致命错误。
PHP调用第三方库报错时，为什么不能直接改全局 autoloader？
因为多数报错本质是命名空间冲突、类重复加载或 composer autoload 机制被破坏——比如你手动 require 了某个库的文件，又让 Composer 自动加载同一类，就会触发 Fatal error: Cannot declare class。这类错误表面看是“第三方库出问题”，实际是加载秩序失控。
隔离不是为了掩盖错误，而是把不可信代码关进沙盒：不让它的 autoload、define()、全局函数污染主流程。
- 别在入口文件或框架核心里
require_once 'vendor/some-lib/bootstrap.php' - 避免在
__autoload或spl_autoload_register中混入非 Composer 管理的逻辑 - 确认
composer.json的autoload段没误配路径（如把psr-4映射到根目录）
用 composer create-project 隔离测试第三方库
不依赖现有项目环境，新建最小可复现场景——这是定位“是不是我项目配置带偏了”的最快方式。
执行：
立即学习“PHP免费学习笔记（深入）”；
composer create-project --no-install phpunit/phpunit:9.6 tmp-test cd tmp-test composer require guzzlehttp/guzzle:^7.5
然后写个独立脚本 test-guzzle.php：
get('https://httpbin.org/get')->getStatusCode();
如果这里报错，说明是 Guzzle 自身或 PHP 环境问题；如果正常，那原项目里大概率有自定义 ClassLoader、重写了 __DIR__ 常量、或启用了 opcache.enable_cli=1 导致缓存了旧类定义。
require_once + set_error_handler 只能捕获部分错误
require_once 不会阻止语法错误、扩展缺失（如 cURL 扩展未启用）或 declare(strict_types=1) 冲突——这些在解析/编译阶段就挂了，set_error_handler 根本收不到。
真正能隔离运行时异常的，是 try/catch 包裹 new 或方法调用，但前提是类已成功加载。所以顺序必须是：
- 先确保
class_exists('Some\ThirdParty\Class')返回true - 再用
try { $obj = new Some\ThirdParty\Class(); } catch (Throwable $e) { ... } - 对扩展依赖，用
extension_loaded('curl')或function_exists('curl_init')提前守门
生产环境禁用 display_errors 后，如何看到真实错误？
很多“藏错”其实是把错误输出关了，但日志没开——结果你以为跑通了，其实 file_get_contents('https://api.example.com') 因 SSL 证书失败静默返回 false，后续逻辑全错。
检查三处：
-
error_log配置是否指向有效文件（tail -f /var/log/php_errors.log实时看） - 第三方库是否自带日志开关（如 Guzzle 的
['http_errors' => false, 'verify' => false]会吞掉 HTTPS 错误） - 是否用了
@抑制符（@file_get_contents()），它连error_log都绕过
复杂点在于：有些库（如 old Zend Framework 组件）会在内部 trigger_error 但不抛异常，这种必须靠日志，没法靠 try/catch 捕获。
