PSR-4查找在高频调用下变慢是因为每次类加载需拼接路径、调用file_exists()检查及require_once，三者均为I/O操作，高并发时叠加成毫秒级延迟；尤其当命名空间与目录不匹配、PSR-4映射过多、realpath缓存或OPcache未启用时，开销被显著放大。
PSR-4 查找为什么在高频调用下变慢
因为每次 new SomeClass() 或 use SomeClass 触发 autoload 时，PSR-4 加载器必须做三件事：拼接路径字符串、调用 file_exists() 检查文件是否存在、再 require_once。这三步全是 I/O 操作，在未启用 OPcache 或缓存未命中的情况下，每类调用都要走一遍磁盘 —— 对一个每秒处理数百请求的 API 来说，几十个类加载叠加起来就是毫秒级延迟。
哪些场景会让 PSR-4 开销被放大
不是所有项目都一样慢，以下情况会显著加剧开销：
-
file_exists()调用频繁且路径拼错（比如命名空间与目录结构不严格对应），导致多次失败尝试后才 fallback 到下一个 autoloader - 项目启用了大量 Composer 包，每个包都有自己的 PSR-4 映射，
spl_autoload_register队列变长，匹配顺序靠后的映射要等前面全部失败 - PHP 的
realpath_cache_size过小或被禁用，每次file_exists()都是真实系统调用，无法利用 realpath 缓存加速 - OPcache 未启用，或
opcache.enable_cli=0导致 CLI 场景（如队列任务、命令行脚本）完全没缓存，autoload_classmap.php 本身也未被缓存
怎么确认你的 PSR-4 正在拖慢性能
别猜，直接验证：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
strace -e trace=file php -r "require 'vendor/autoload.php'; new App\Service\User();"看是否出现大量stat()和openat()调用 - 运行
php -d xdebug.mode=profile -r "require 'vendor/autoload.php';"，再用kcachegrind查看ComposerAutoloadClassLoader::findFile占比是否超 15% - 检查
opcache_get_status()['scripts']中是否有vendor/composer/autoload_real.php和autoload_classmap.php—— 如果没有，说明 OPcache 根本没生效，PSR-4 优化再好也白搭
psr-4 和 classmap 混用时的真实行为
Composer 不是“选一个用”，而是按固定顺序尝试：classmap → psr-4 → files。这意味着：
- 只要
autoload_classmap.php里有对应类名，就直接跳过 PSR-4 所有逻辑，哪怕你根本没配"classmap"字段 —— 因为-o会把 PSR-4 映射也扁平化进 classmap - 但若用了
--classmap-authoritative，一旦 classmap 里没这个类，就立刻报错，不再往下走 PSR-4；所以漏扫 = 线上故障 - 如果你只加了
"psr-4": {"App\": "src/"}，却没运行composer dump-autoload -o，那 classmap 文件里只有空数组或极少量条目，高频调用仍全走 PSR-4
真正起效的关键不在配置写得多漂亮，而在部署时有没有跑对命令、生成的文件有没有被 OPcache 接住、以及 classmap 是否覆盖了你实际高频使用的那些类 —— 这三点漏掉任何一环，PSR-4 的查找开销就还在那儿等着你。
