通过检查 vendor/autoload_classmap.php 是否存在且非空，或运行 composer dump-autoload -v 观察是否输出“Generating optimized autoload files (using classmap)”来判断是否启用 classmap；classmap 优先级高于 PSR-4，但仅对静态类有效，启用 --classmap-authoritative 后将完全跳过文件系统扫描。
composer dump-autoload 时怎么知道用了 classmap 还是 PSR-4？
直接看 vendor/autoload_classmap.php 文件是否存在且非空——它只在启用 classmap 优化时生成。如果这个文件是空的、不存在，或者只有 return array();，说明当前没走 classmap 加载路径。
更可靠的方式是执行：
composer dump-autoload -v，观察终端输出里是否出现
Generating optimized autoload files (using classmap) 这类提示。注意：仅当 composer.json 中显式配置了 "classmap" 字段（哪怕只是空数组），或运行过 composer dump-autoload --classmap-authoritative，才会真正触发 classmap 构建。
-
"psr-4"是默认行为，只要没配classmap，autoload 就走映射表 + 文件系统查找 -
"classmap"配置项里填的是目录或文件路径，不是命名空间前缀；它和 PSR-4 可共存，但 classmap 优先级更高 - 运行
composer install默认不生成 classmap，除非加--optimize-autoloader或已开启optimize-autoloader=true配置
为什么 vendor/autoload.php 有时快有时慢？关键看 autoload_files 和 classmap 是否生效
PSR-4 的本质是「运行时拼路径 + file_exists 检查」，每次 new 一个类都可能触发多次磁盘 I/O；而 classmap 是把所有类路径提前打成一张静态数组，vendor/autoload.php 直接 require 它，跳过查找过程。
但 classmap 不是万能加速器：它只对「确定存在且不会动态生成」的类有效。比如测试文件、带条件加载的 trait、或通过 eval() / include 动态引入的类，进不了 classmap。
- 启用
--classmap-authoritative后，Autoloader 会完全跳过文件系统扫描，只查 classmap —— 这时漏掉的类会直接报Class not found -
"files"类型的自动加载（如函数库）不受 classmap 影响，始终在启动时 require - PHP OPcache 开启时，classmap 文件本身会被缓存，但 PSR-4 的路径拼接逻辑仍需执行，这部分开销无法消除
如何验证某个包是否被 classmap 覆盖？
最直接的办法：去该包的 vendor/{vendor}/{package}/ 目录下，找它的 composer.json，检查是否有 "classmap" 字段，并确认字段值指向的路径下确实存在 PHP 类文件。
例如 laravel/framework 的 composer.json 有：
"classmap": [<br> "src/Illuminate/Foundation/AliasLoader.php",<br> "src/Illuminate/Foundation/helpers.php"<br>]，这些文件就会被扫进全局 classmap。
- 如果包只声明了
"psr-4"，没写"classmap"，那它不会进入 classmap —— 即使你本地执行了composer dump-autoload --optimize-autoloader - 第三方包的 autoload 配置以它自己的
composer.json为准，父项目的配置不能覆盖它 - 用
composer show {vendor}/{package}看不到 autoload 详情，必须打开它的源码 composer.json
classmap vs PSR-4 性能差异到底有多大？
单次类加载差距微乎其微（纳秒级），但高并发或大量反射场景下，classmap 确实更稳：它消除了 file_exists() 和路径拼接的不确定性，也绕过了某些文件系统权限或 symlink 问题。
不过真实瓶颈往往不在 autoload 本身，而在类初始化逻辑、DI 容器解析、或 OPcache 是否命中。盲目加 --optimize-autoloader 可能让 composer install 变慢几秒，却对请求耗时不产生可测提升。
- CLI 环境下 classmap 优势明显（无 OPcache，频繁 reload）
- Web 环境中若 OPcache 全局启用且配置合理，PSR-4 和 classmap 的实际耗时差通常低于 0.1ms
- 真正要警惕的是混合使用：比如一个包同时声明了
"psr-4"和"classmap"，又没清理旧 classmap 缓存，可能导致类从两个路径被加载，引发 fatal error
--classmap-authoritative，任何未被扫描到的类都会静默失败，连 autoloader 的 fallback 机制都没机会触发**。 
