Composer 的 autoload 是通过配置生成 PSR-4/PSR-0 自动加载逻辑，而非手写加载器；手动 require autoload.php 会绕过依赖管理与优化，易引发冲突；应优先使用 composer.json 中的 "psr-4" 配置并执行 dump-autoload。
Composer 的 autoload 不是让你从零写加载器，而是通过配置让 Composer 生成符合 PSR-4/PSR-0 规范的自动加载逻辑；手写 autoload.php 并直接 require 它，会绕过 Composer 的依赖管理和类映射优化，极易引发冲突或失效。
PSR-4 配置比手写加载器更安全、更高效
Composer 默认使用生成的 vendor/autoload.php，它内部基于 PHP 的 spl_autoload_register() 注册多个 loader，其中 PSR-4 映射由 ComposerAutoloadClassLoader 实现——这个类已针对文件存在性、命名空间前缀、目录扫描做了缓存和短路优化。
- 在
composer.json中声明"psr-4": {"MyApp\": "src/"}即可，无需写任何 PHP 加载逻辑 - 运行
composer dump-autoload后，vendor/composer/autoload_psr4.php会生成静态映射数组，比每次file_exists()判断快得多 - 若手动实现类似逻辑，容易漏掉对
\和/路径分隔符的兼容、未处理尾部反斜杠、忽略大小写敏感问题（尤其在 Windows 上）
何时需要自定义 autoload 逻辑？只有一种合理场景
仅当你要加载非标准路径结构的类（比如插件目录动态发现、运行时拼接的命名空间），且无法用 PSR-4 的多前缀配置覆盖时，才应通过 autoload-dev 或 files 字段引入辅助加载器。
-
"files": ["src/helpers.php"]：适合全局函数，Composer 会在每次加载时require_once这些文件 -
"autoload": {"classmap": ["legacy/"]}：用于老项目中无命名空间的类，Composer 会扫描并生成路径映射表 - 绝对不要在
autoload.php里调用spl_autoload_register()去覆盖或追加默认行为——这会导致类加载顺序混乱、重复注册、class_exists()行为异常
调试 autoload 失败：先看生成的映射文件，别急着改代码
类找不到（Class 'MyAppFoo' not found）时，优先检查 Composer 是否真的生成了对应映射，而不是怀疑加载器没生效。
- 打开
vendor/composer/autoload_psr4.php，确认"MyApp\"键是否存在，对应路径是否为绝对路径（如/path/to/project/src） - 执行
composer show -p查看当前 autoloader 使用的加载策略（PSR-4 / classmap / files） - 用
composer dump-autoload -o启用优化模式，它会把 PSR-4 映射合并进一个大数组，同时生成autoload_classmap.php，可用来验证类名是否被收录 - 注意：修改
composer.json后必须运行dump-autoload，否则更改不生效——这点极易被忽略
真正难的不是写加载逻辑，而是理解 Composer 如何把你的配置翻译成 ClassLoader::prefixLengthsPsr4 和 fallbackDirsPsr4 这些内部属性；一旦依赖生成的映射文件，就别试图用 include 或 require 手动模拟它。
