运行时 addPsr4() 不生效是因为 Composer autoload 在启动时固化查找逻辑，findFile() 默认不扫描后期添加的映射，需确保操作的是已注册的 ClassLoader 实例、前缀以双反斜杠结尾、路径真实存在且有读权限，并在长生命周期进程中先 unregister 再 register 以避免冲突。
运行时 addPsr4() 为什么经常不生效
因为 Composer 的 autoload 机制在脚本启动时就固化了查找逻辑，ClassLoader::addPsr4() 只是往内部数组里塞映射，但默认 findFile() 不会扫描这些“后期添加”的条目——除非你操作的是当前正在使用的那个 ClassLoader 实例，并且它已注册进 PHP 的自动加载栈。
常见错误现象：Class not found 即使路径存在、命名空间写对、addPsr4() 调用成功；或者只在部分请求中生效（尤其 Swoole/Workerman 长生命周期进程）。
- 必须从
vendor/autoload.php获取实例：$loader = require 'vendor/autoload.php';，而不是new ClassLoader() - 调用
addPsr4()后，必须确保该前缀以双反斜杠结尾，例如'App\Fix\' => '/tmp/fix/'，少一个\就匹配失败 - 路径必须真实存在且 PHP 进程有读权限（CLI 下
/tmp目录权限问题很常见） - Web 环境每次请求都要重新注入（不能只在入口文件写一次就完事）
如何让动态注入的 PSR-4 在长生命周期进程中稳定生效
Swoole 或 Workerman 中，vendor/autoload.php 通常只在 Worker 启动时加载一次，后续请求复用同一个 ClassLoader 实例。这时如果热修复类路径变了，旧映射还在内存里，新 addPsr4() 可能被忽略或顺序错乱。
最稳妥做法是先清空再重装，避免同名前缀冲突：
- 调用
$loader->unregister()卸载当前 loader - 用
$loader->addPsr4('App\Service\', '/hotfix/service/')注入新路径 - 再调用
$loader->register()重新挂载 - 注意：不要在协程中并发调用
register()，可能引发竞态
用 addClassMap 精确覆盖单个类更安全
如果你只想替换某个具体类（比如 App\Service\UserService），addClassMap() 比 addPsr4() 更可靠——它绕过路径拼接逻辑，直接建立类名到文件的硬映射。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
示例：
$loader->addClassMap([
'AppServiceUserService' => '/tmp/fix/UserService.php',
]);
关键点：
- 类名必须是完全限定名，去掉反斜杠并替换为单反斜杠：
App\Service\UserService→AppServiceUserService - 文件路径必须绝对且可读，不能是相对路径
- 它不会影响其他类，也不会和原有 PSR-4 规则冲突
- 适合灰度发布、AB 测试或紧急 hotfix 场景
为什么 dump-autoload 对运行时注入没用
composer dump-autoload 生成的是 vendor/composer/autoload_psr4.php 这个静态快照文件，只供 vendor/autoload.php 初始化时加载。运行时通过 API 注入的规则完全不走这个文件，而是靠 ClassLoader 实例内部维护的数组。
所以别指望改完 composer.json 再跑一遍 dump-autoload 就能让 addPsr4() 生效——那是两套机制。
容易被忽略的地方：Swoole Worker 重启后，所有运行时注入都会丢失，必须在 Worker 启动回调里重新执行注入逻辑；而 CLI 命令每次都是新进程，反而更容易控制。
