优化自动加载需三步：写对autoload映射、用对dump-autoload参数、区分开发与生产环境；composer.json中设"optimize-autoloader": true仅启用优化开关，须配合-o参数生效，且不扫描未声明目录。
直接结论：优化自动加载不是改几行配置就完事，关键在三步——写对 autoload 映射、用对 dump-autoload 参数、区分开发与生产环境行为。
composer.json 里怎么开 optimize-autoloader
在 composer.json 根对象下加字段："optimize-autoloader": true。它本身不改变映射逻辑，只告诉 Composer 后续生成 autoload 文件时启用类映射优化。
- 这个开关仅影响
composer dump-autoload -o、composer install -o或composer update -o的输出，单独设了但不带-o参数，不会生效 - 它不会自动扫描未声明的目录；比如你只配了
"psr-4": {"App": "src/"}，那vendor/autoload.php就只认src/下的类，lib/里新增的类哪怕符合命名空间也找不到 - 开发阶段建议先别开，否则新增类后忘记
dump-autoload -o，会卡在 “Class not found” 却查不出路径问题
dump-autoload -o 和 -a 的区别到底在哪
composer dump-autoload -o 是常规优化：把 PSR-4 规则预编译成静态数组，跳过运行时拼路径和文件存在性检查；而 -a（--classmap-authoritative）是激进模式：一旦类不在 classmap 里，就直接报错，不再 fallback 到 PSR-4 查找。
-
-o仍保留 PSR-4 的兜底能力，适合大多数项目 -
-a要求你必须确保所有类都在autoload.classmap或autoload.psr-4声明范围内，漏一个，class_exists()就返回false - 两者可共存：
composer dump-autoload -o -a，但-a依赖-o生成的 classmap 数据，没-o单独用-a无效
为什么开了 optimize-autoloader 还是慢
常见原因不是配置没开，而是 autoload 映射本身有冗余或冲突。
- 多个
psr-4前缀指向同一目录（如"App": "src/"和"App\Http": "src/"），Composer 会依次匹配，拖慢前缀查找 -
autoload.files里引入了重型初始化逻辑（比如连接数据库、加载大数组），这些代码在每次请求早期就被执行，和类加载无关却拖累首字节时间 - 用了
classmap-authoritative但没清空旧的vendor/composer/autoload_classmap.php，导致缓存残留，新类始终不进 map - OPcache 没启用或没预热，优化后的 autoload_static.php 文件无法被有效缓存
autoload-dev 配置要不要加 optimize-autoloader
不用。因为 autoload-dev 只在 composer install --dev 或 composer dump-autoload --dev 时生效，而 optimize-autoloader 是全局开关，对 autoload-dev 不起作用。
- 测试类（如 PHPUnit）是否走优化加载，取决于你运行测试时用的是不是
vendor/autoload.php—— 它默认已包含autoload-dev规则，只要你在phpunit.xml的bootstrap里正确指向它即可 - 如果手动执行
composer dump-autoload --dev -o，它会生成独立的优化版 dev autoloader，但多数框架（Laravel、Symfony）不读这个，只认主vendor/autoload.php - 真正要优化测试加载速度，应检查测试启动流程是否重复 require、是否启用了 PHPUnit 的
--bootstrap缓存机制
最易被忽略的一点：优化不是一劳永逸。只要改了类名、移动了文件、调整了命名空间，就必须重新 dump-autoload -o；Composer 不监听文件变化，也不会在 composer install 时自动触发，靠人记。
