spl_autoload_register注册的加载器按FIFO顺序执行，任一成功require即终止后续调用；类名大小写敏感且为完整命名空间字符串，路径需用DIRECTORY_SEPARATOR转换反斜杠，PSR-4前缀须严格匹配。
spl_autoload_register 注册的多个加载器，按调用顺序依次执行；只要有一个成功 require 到类文件，后续加载器就完全不触发。这是排查“类找不到”问题的核心逻辑起点。
多个 spl_autoload_register 回调的执行顺序是注册顺序，不是文件路径顺序
PHP 不会合并或排序你注册的加载器，它只维护一个 FIFO 队列：先 spl_autoload_register(A)，再 spl_autoload_register(B)，那么每次类未定义时，一定先调用 A，A 返回（无论成功失败）后才轮到 B。
- 即使 A 对应的目录里根本没这个类，只要它没报错、没抛异常、也没
require成功，B 就一定会被执行 - 但如果 A 里写了
throw new Exception()或trigger_error(..., E_ERROR)，整个自动加载过程立刻中断，B 根本不会运行 —— 这是常见静默失败原因 - 注意：
require_once加载失败（如文件不存在）只是 warning，默认不中断执行；但require在文件不存在时是 fatal error，直接终止脚本，后续加载器也无从谈起 - 验证顺序最简单的方式：在每个回调开头加
error_log("loading via A: $class")，看日志输出顺序
类名传入 spl_autoload_register 回调时是完整命名空间字符串，大小写敏感
比如 new AppControllerUserService()，回调收到的参数是字符串 'AppControllerUserService'（双反斜杠是 PHP 字符串转义结果，实际值是单反斜杠），不是 'UserService' 或 'appcontrolleruserservice'。
- Linux 系统下路径和类名大小写必须完全一致，
App\Models\User和文件src/Models/user.php无法匹配 - 命名空间里的反斜杠
必须转成目录分隔符：str_replace('\', DIRECTORY_SEPARATOR, $class)，不能硬写/（Windows 下会出错） - PSR-4 映射要求前缀严格匹配，例如注册了
"App\": "src/"，那AppSub\Foo不会被这个规则捕获 —— 它不属于App\前缀 - 调试时可直接
var_dump($class)看实际传入值，别靠猜测
加载失败时不会报具体哪一步出错，只抛 Fatal error: Class "X" not found
这个错误是最终兜底结果，意味着所有已注册的 autoload 回调都走完了，没人 require 成功，PHP 放弃抢救。它不能被 try/catch 捕获，因为属于 fatal error 级别。
立即学习“PHP免费学习笔记（深入）”；
- 检查点优先级：类名拼写 → 命名空间声明（
namespace AppController;）→ 文件路径是否真存在（用file_exists($path)打印出来核对）→ 文件内是否真有class UserService（而非class userservice或拼错） - 不要依赖
require_once的静默行为：在回调里加上if (!file_exists($path)) { error_log("MISSING: $path"); return; }，快速定位漏掉的路径 - 如果用了 Composer，确认
vendor/autoload.php是最早include的（通常放在入口文件第一行），否则你自定义的加载器可能先跑，而 Composer 的 PSR-4 规则还没生效 - PHP 7.4 不支持
__autoload，如果旧代码里还留着这个函数，又没显式spl_autoload_register('__autoload')，它会被完全忽略 —— 不会自动 fallback
最容易被忽略的是：某个 autoload 回调里做了 return 或提前 exit，导致后续加载器永远没机会执行；或者路径拼接时忘了加 .php 后缀，file_exists 一直返回 false 却没日志提示。这类问题不会报错，只会让类“神秘消失”。
