必须用spl_autoload_register——它支持多回调、可设优先级、能抛异常、兼容Composer；__autoload已弃用并移除。
PHP自动加载靠__autoload还是spl_autoload_register？
用__autoload已经不安全也不推荐了——它只允许定义一个全局加载函数，一旦第三方库也注册了__autoload，就会被覆盖。PHP 7.2 起已弃用，PHP 8.0 完全移除。
必须用spl_autoload_register，它支持多回调、可控制优先级、能抛出异常、兼容 Composer 生态。
实操建议：
- 每个项目只调用一次
spl_autoload_register，把所有类映射逻辑封装进一个闭包或静态方法里 - 不要在多个文件里反复调用
spl_autoload_register注册匿名函数，容易重复注册、触发多次加载 - 如果用了 Composer，别自己写 autoload —— 直接
require 'vendor/autoload.php'，它内部就是基于spl_autoload_register实现的
类名到文件路径的映射规则怎么写才不翻车？
自动加载失败，八成出在路径拼错或命名不匹配。PHP 不会猜你把UserController放在app/Controllers/User.php还是src/Http/Controllers/UserController.php，一切取决于你怎么解析$class参数。
常见错误现象：
立即学习“PHP免费学习笔记（深入）”；
- 类存在但报
Class 'AppUser' not found：路径没对应上命名空间 - 文件存在但加载失败：扩展名写成
.php5或漏了.php - 大小写敏感问题：Linux 下
user.php和User.php是两个文件，但new User()只会找User.php
推荐做法：
- 严格遵循 PSR-4：命名空间前缀 + 目录路径一一对应，比如
AppControllers→src/Controllers/ - 用
str_replace和dirname(__DIR__) . '/src/'拼路径，别硬编码../app/这种相对路径 - 最后一定要加
.php后缀，且用file_exists()判断再require，避免require失败导致致命错误
为什么require_once在自动加载里是错的？
自动加载函数里用require_once看似稳妥，实则埋雷：它依赖 PHP 内部的已加载文件列表，而这个列表在 CLI 和 FPM 模式下行为不一致；更严重的是，当同一个类被不同 autoloader 加载（比如你写了自定义 loader，又引入了 Composer），require_once可能跳过本该执行的初始化逻辑。
正确做法只有这一种：
- 统一用
require（不是include，也不是require_once） - 确保每个类文件只被一个 autoloader 处理 —— 也就是提前用命名空间/前缀做过滤，不兜底加载所有
*.php - 如果真需要防重复加载，靠 PSR-4 的前缀隔离，而不是靠
_once语义
Composer autoload 配置写错会导致什么？
很多人以为只要composer.json里写了"autoload"，就能“自动”工作。其实 Composer 只在运行composer dump-autoload时生成vendor/composer/autoload_*.php文件，这些文件才是实际被vendor/autoload.php加载的东西。
典型配置错误：
-
"psr-4": {"App\": "app/"}写成{"App\": "app"}（缺结尾斜杠）→ 自动加载器会去找appControllers/而非app/Controllers/ -
"classmap"指向目录但没运行composer dump-autoload --optimize→ 新增类不会被发现 - 修改了
composer.json但忘了composer install或dump-autoload→ 配置永远不生效
调试技巧：运行composer show -p看当前加载的路径映射，比翻代码快得多。
真正麻烦的从来不是写几行spl_autoload_register，而是命名空间、目录结构、PSR 规则、Composer 缓存这四者咬合出的一丁点偏差 —— 差之毫厘，Class not found就报得毫无商量余地。
