必须配合命令行参数和显式classmap声明才能真正提速：仅设"optimize-autoloader":true无效，需用composer dump-autoload -a生成classmap，并在autoload中声明目录，生产环境可加--classmap-authoritative --no-dev --optimize-autoloader。
直接结论：只改 composer.json 的 "config" 段不足够，必须配合命令行参数 + 明确的 autoload 声明才能真正提速。
为什么单纯在 config 里加 "optimize-autoloader": true 没用
这个配置项只是“默认开启优化开关”，但不会自动触发 classmap 生成；它只在 composer install 或 composer update 时起作用。如果本地开发一直用 composer dump-autoload，那这个配置根本不会被读取。
- 常见现象：改了
composer.json后跑composer dump-autoload -o，vendor/composer/autoload_classmap.php还是空的或没更新 - 根本原因：-o 参数只对当前命令生效，而
dump-autoload默认不扫描 PSR-4 目录以外的路径（比如tests/、bin/），除非你显式写了"classmap"配置 - 更隐蔽的问题：如果你的
autoload.ps4里声明了"App\": "src/"，但实际类文件放在src/Controllers/V1/且命名不规范（如User_Controller.php），Composer 扫描时会跳过——classmap 就漏掉了这些类
autoload.classmap 是唯一能兜底的声明方式
PSR-4 是“按需查找”，classmap 是“全量预存”。要让优化真正覆盖所有类，就得放弃依赖自动发现，主动告诉 Composer 哪些目录必须扫。
- 在
composer.json的"autoload"下加："classmap": ["src/", "app/", "lib/", "database/seeders/"]
- 删掉冗余的 PSR-4 条目——比如
"App\": "src/"和"classmap": ["src/"]同时存在，Composer 仍会优先走 PSR-4 路径，classmap 反而闲置 - 运行
composer dump-autoload -a（不是 -o）：-a 表示强制重扫 classmap，-o 只是启用已有的 classmap 加载逻辑 - 验证：打开
vendor/composer/autoload_classmap.php，搜索一个你刚加进src/的新类名，看路径是否正确映射
--classmap-authoritative 必须和 --no-dev 一起用
这个参数让 Composer 完全信任 classmap，一旦类不在里面就直接报错，不再 fallback 到 PSR-4。它快，但危险。
- 只应在生产部署时启用：
composer install --classmap-authoritative --no-dev --optimize-autoloader - 不能在开发中开：你新增一个
src/Services/PaymentService.php，忘了运行dump-autoload -a，立刻 Class not found - CI/CD 中尤其要注意：如果构建镜像时用了
--no-dev，但本地composer.json的"require-dev"里有测试工具（如phpunit），它们的类可能也被扫进了 classmap——结果线上报错找不到PHPUnitFrameworkTestCase - 替代方案：用
--apcu-autoloader更安全，它缓存的是加载器实例，不是 classmap 内容本身，类缺失时仍可 fallback
真正卡住性能的往往不是 classmap 本身，而是 opcache 没预热、APCu 配置了但 apc.stat=1、或者 vendor/autoload.php 文件太大导致 opcache 编译慢。优化配置只是第一步，后面得看 PHP 层是否接得住。
