PHP自动加载机制靠spl_autoload_register()，__autoload()自PHP 7.2+起废弃，8.0+彻底移除；它支持多注册、可取消、不冲突，Composer也完全基于它实现。
PHP自动加载机制靠__autoload()还是spl_autoload_register()？
PHP 7.2+ 已废弃__autoload()，必须用spl_autoload_register()——它支持多注册、可取消、不干扰其他框架的加载逻辑。直接写__autoload()函数在现代项目里会报Deprecated警告，且 Composer 生成的 autoload 文件也完全基于spl_autoload_register()。
实操建议：
- 永远不要定义全局
__autoload()函数； - 多个加载器可共存：
spl_autoload_register('my_loader')和spl_autoload_register('vendor_loader')互不冲突； - 若需移除某个加载器，保存注册返回的匿名函数引用，再用
spl_autoload_unregister($handler)； - 注意执行顺序：后注册的先执行（LIFO），调试时可用
spl_autoload_functions()查看当前全部注册项。
Composer autoloader 的classmap和psr-4怎么选？
classmap适合老旧类文件（无命名空间、文件名不规则）、或想极致加速单次加载（如 CLI 工具）；psr-4是标准做法，依赖目录结构映射命名空间，开发友好、可动态发现新类。
常见错误现象：
立即学习“PHP免费学习笔记（深入）”；
- 用了
psr-4但类文件放在src/Utils/Helper.php，而composer.json里却配成"App\": "src/"→ 加载AppUtilsHelper失败，因为实际路径对应的是AppUtilsHelper，但文件里声明的是namespace Utils;； - 修改
psr-4映射后没运行composer dump-autoload→ 新增类始终“找不到”； - 混用
classmap和psr-4时，classmap优先级更高，但它的映射是静态生成的，新增类不会自动加入，容易漏加载。
自定义加载器里，require_once和include_once哪个更安全？
必须用require_once。类文件缺失时，include_once只发Warning并继续执行，后续new Xxx()会直接Fatal error: Class 'Xxx' not found；而require_once抛Fatal error更早暴露问题，避免静默失败。
实操细节：
- 路径拼接务必用
realpath()或__DIR__ . '/..' . $file，避免相对路径在不同include_path下失效； - 检查文件是否存在再
require_once，否则require_once失败会中断整个请求； - 别在加载器里做太多逻辑（如日志、网络请求），它可能被高频调用，影响性能；
- 如果类名含非法字符（如
MyClass@v2），require_once前应过滤或拒绝加载，防止路径遍历风险。
为什么autoload.php要放在vendor/autoload.php而不是项目根目录？
不是“必须”，而是 Composer 默认约定：所有依赖包的自动加载逻辑统一由vendor/autoload.php聚合输出，它内部已按顺序加载classmap、psr-4、files等配置。你手动把autoload.php放到项目根目录，反而会绕过 Composer 的自动管理，导致 vendor 包里的类无法加载。
关键点：
- 项目入口（如
index.php）第一行必须是require __DIR__ . '/vendor/autoload.php';； - 不要复制或重写
vendor/autoload.php内容到自己文件里——它每次composer install都会重生成； - 想加自己的加载逻辑？用
spl_autoload_register()在vendor/autoload.php之后注册，而不是替换它。
最常被忽略的是：改了composer.json的 autoload 配置后，忘了运行composer dump-autoload -o（优化模式）来生成 classmap 缓存——尤其在生产环境，没加-o会导致每次类加载都扫描整个目录。
