composer类映射优化需主动收拢路径、关闭fallback并验证结果；仅-o不生效，因默认保留psr-4 fallback扫描；应配合--classmap-authoritative、--no-dev及正确配置classmap字段，并确保opcache启用且预热。
Composer类映射优化不是“加个-o就完事”，它只在你主动收拢路径、关闭fallback、验证生成结果时才真正生效。
为什么composer dump-autoload -o后加载还是慢
因为-o只是触发classmap生成，但默认仍保留PSR-4 fallback：一旦autoload_classmap.php里没找到类，Composer会立刻退回到目录扫描+file_exists()判断——这步开销和没优化前几乎一样。
- 检查
vendor/composer/autoload_classmap.php是否真包含你的核心类（如'app\Http\Controllers\HomeController'） - 确认没把
tests/或examples/误塞进classmap字段，它们会拖慢扫描且无实际用途 - 运行
composer install --no-dev --optimize-autoloader而非仅dump-autoload，前者会强制启用优化链路
如何让classmap覆盖全部关键类
别依赖自动扫描，手动指定稳定目录。ThinkPHP的app/和common/默认走PSR-4，必须显式加入composer.json的"classmap"字段才能被-o捕获。
- 在
composer.json中添加："autoload": { "psr-4": { "app\": "app/", "common\": "common/" }, "classmap": ["app/", "common/", "library/Utils/"] } - 运行
composer dump-autoload -a（-a比-o更彻底，强制重扫所有classmap路径） - 删掉重复的PSR-4声明（例如
"app\": "app/"和"classmap": ["app/"]共存），避免同一类被注册两次
生产环境必须加--classmap-authoritative
这个参数告诉Composer：“映射表就是全部，找不到就报错，别再扫文件系统”。它能砍掉一次stat()系统调用，在高并发下效果明显。
- 部署脚本里统一用：
composer install --no-dev --optimize-autoloader --classmap-authoritative - 禁用
opcache.stat=0，否则每次require都会重新检查文件修改时间，废掉classmap优势 - APCu缓存的是autoloader实例，不是
autoload_classmap.php内容本身；若用--apcu-autoloader，需确保apc.enabled=1
开发阶段别硬套生产优化
频繁增删类时，composer dump-autoload -o会成为负担：每次改完都得重跑，IDE断点可能失效，热重载工具无法发现新文件。
- 开发环境保持
"optimize-autoloader": false（或不设），用基础PSR-4加载 - 需要临时提速可单独对稳定模块做classmap，比如只加
"library/SDK/"，不动app/ - 切记：classmap不支持运行时动态
require的文件，这类逻辑要保留在filesautoload段里
最容易被忽略的点是：classmap是否真的被加载器读取。哪怕autoload_classmap.php里有类，如果composer install没带--optimize-autoloader，或者OPcache没预热，PHP进程依然走的是未优化路径。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
