set_exception_handler() 在 require vendor/autoload.php 后才有效，因为 Composer 自动加载基于 spl_autoload_register()，仅未捕获的 Exception 类异常触发该处理器；而 Class not found 等致命错误属 Error 子类，需 set_error_handler() 拦截 E_ERROR 并匹配 "Class not found" 消息。
为什么 set_exception_handler() 在 require vendor/autoload.php 后才有效？
因为 Composer 的自动加载器本身基于 spl_autoload_register()，而 PHP 的异常处理器只对未被捕获的异常生效；autoload 过程中抛出的 ParseError、TypeError 或自定义 Exception，若没被 try/catch 拦截，才会落到全局 handler。但注意：autoload 阶段发生的 FatalError（如语法错误、类继承冲突）在 PHP 8+ 中是 Error 子类，必须用 set_error_handler() + error_get_last() 辅助捕获，仅靠 set_exception_handler() 不够。
如何精准拦截 PSR-4 映射失败导致的 Class not found？
PSR-4 查找失败本身不会抛异常，而是静默返回 false，最终触发 PHP 的致命错误 Fatal error: Uncaught Error: Class "XYZ" not found。这不是 Exception，而是 Error，无法被 set_exception_handler() 捕获。真正能拦截它的，是 set_error_handler() 对 E_ERROR 的响应，但默认不触发——必须提前启用：
- 确保
error_reporting()包含E_ERROR（通常默认开启） - 在
require vendor/autoload.php前注册 handler，并检查$severity === E_ERROR且$message包含"Class not found" - 用
str_contains($message, 'Class not found')判断，避免误捕其他 E_ERROR
autoload_classmap.php 和 autoload_psr4.php 的加载顺序影响拦截逻辑
Composer 自动加载器按固定优先级尝试策略：先查 classmap，再走 psr-4，最后 fallback 到 files。这意味着：
- 如果你在
classmap中漏掉了某个类，它会跳过 classmap 直接进 PSR-4 流程，此时拦截点在 PSR-4 路径拼接后file_exists()返回 false 的瞬间——但这个过程不抛错，只有后续实例化时才报错 -
autoload_psr4.php是一个关联数组，键为命名空间前缀（如"App\"），值为根目录路径；它的结构决定了你能通过array_keys($psr4)快速校验是否覆盖了目标命名空间 - 想提前发现映射缺失，可在
dump-autoload后读取vendor/composer/autoload_psr4.php，检查目标前缀是否存在，而不是等运行时报错
自定义 ClassLoader 实例时，addClassMap() 和 addPsr4() 的调用时机很关键
如果你手动接管 autoload（例如在测试环境或插件系统中），直接 new ClassLoader 后调用 addPsr4()，必须在 register() 之前完成所有映射注册。否则：
- 映射未注册就
register()，会导致该前缀完全不可用 -
addClassMap()接收的是完整类名 → 文件路径数组，它比 PSR-4 更快，但无法动态推导新类——适合稳定核心类，不适合开发期频繁增删 - 多个
addPsr4()调用允许同一前缀映射多个路径，Composer 默认按数组顺序查找，第一个存在对应文件的路径胜出
真正容易被忽略的是：手动实例化的加载器不会自动读取 composer.json 的 autoload 配置，所有映射都得你显式写死，漏一条就等于关掉一扇门。
