classloader 支持运行时扩展但非热更新：addpsr4()等方法仅对后续类加载生效，需复用已注册实例、用绝对路径、命名空间末尾带反斜杠；psr-4按注册顺序匹配，覆盖需先卸载再添加；autoload.php仅注册自动加载器，不预加载类。
ClassLoader 实例本身支持运行时扩展，但不是“改配置就生效”
Composer 生成的 ClassLoader 实例确实提供了 addPsr4()、addClassMap() 和 register() 等方法，允许你在运行时注入新路径。但它不会自动合并进已生成的静态映射表——你手动加的路径，只对后续类加载生效，且必须确保调用的是当前被 spl_autoload_register() 激活的那个实例。
常见错误是：在 CLI 脚本里 require vendor/autoload.php 后又 new ClassLoader() 并调用 addPsr4()，结果新实例根本没注册，类照样找不到。
- 正确做法是复用
vendor/autoload.php返回的实例：$loader = require __DIR__ . '/vendor/autoload.php'; -
addPsr4()第二个参数必须是绝对路径，相对路径不会自动补全 - 命名空间前缀末尾必须带反斜杠，比如
'AppFix' => '/tmp/fix/'，写成'AppFix' => '/tmp/fix/'就匹配失败 - web 环境下每次请求都要重新执行注入逻辑；Swoole/Workerman 长生命周期进程里则只需一次，但要注意热更新时旧映射残留
PSR-4 映射顺序决定加载优先级，覆盖需谨慎
Composer 的 loadClass() 查找顺序是：classmap → PSR-4 → PSR-0 → fallbackDirs。它不按“后注册优先”，而是遍历所有 PSR-4 前缀，按注册顺序逐个拼路径检查文件是否存在。这意味着你用 addPsr4() 加的新前缀，如果排在原项目 PSR-4 条目之后，就可能被跳过——尤其当原路径下恰好存在同名类文件时。
想稳妥替换已有类（比如热修复），不能只加新路径，得先卸载旧映射：
- 调用
$loader->unregister()暂停当前自动加载器 - 用
removePsr4()或直接操作$loader->prefixesPsr4移除冲突项（注意键名含反斜杠） - 再
addPsr4()新路径，最后$loader->register() - 更精确的做法是改用
addClassMap()，直接绑定类名到文件路径，绕过前缀匹配逻辑
autoload.php 不是“加载全部类”，只是注册 autoloader
很多人误以为 vendor/autoload.php 会把所有类都 require 进来。其实它只做一件事：初始化一个 ClassLoader 实例，并通过 spl_autoload_register() 把它的 loadClass() 方法注册进 PHP 的自动加载队列。真正的文件 I/O 只发生在类首次被引用时（如 new MyClass() 或 use MyClass）。
这也解释了为什么动态添加路径后，已加载过的类不会自动刷新——PHP 内部缓存了类定义，loadClass() 根本不会再被触发。
- 调试类找不到问题，优先打开
vendor/composer/autoload_psr4.php看映射是否生成 - 执行
composer dump-autoload -o后，autoload_classmap.php里能查到所有被收录的类名 - 不要在
autoload.php里再调用spl_autoload_register()，会导致重复注册和顺序错乱
自定义加载逻辑不该绕过 Composer 的 autoload 机制
手写一个 my-autoloader.php 并 require 它，看似灵活，实则危险：它会脱离 Composer 的 classmap 优化、PSR-4 静态映射、以及依赖版本隔离能力。一旦项目里同时存在 Composer 自动加载和你手写的加载器，class_exists()、interface_exists() 的行为可能不一致，autoload 顺序也难以预测。
真正需要“非标加载”的场景（比如插件目录动态扫描），应该用 Composer 的 autoload-dev 或 files 字段引入辅助逻辑，而不是另起炉灶：
-
"autoload": { "files": ["src/helpers.php"] }—— 适合全局函数，每次加载都require_once -
"autoload-dev": { "psr-4": { "Tests\": "tests/" } }—— 开发时可用，生产环境不生效 - 动态路径注入只应在明确生命周期可控的上下文里做（如 PHPUnit 的
setUp()、CLI 命令入口）
ClassLoader 的扩展性，本质是给运行时留了一道缝，不是让你拆墙重砌。缝太窄，用力过猛反而卡住。
