应分场景使用：生产部署前必须执行 composer dump-autoload --optimize（配合 --no-dev），CI/CD 构建镜像时固定运行；开发期禁用，避免迭代延迟及漏载动态文件。
Composer autoload 性能差，八成是因为没跑 composer dump-autoload --optimize 或没启用 classmap 生成；但盲目加 --optimize 在开发期反而拖慢迭代——关键得看场景、分阶段处理。
什么时候该用 composer dump-autoload --optimize
这个命令会把 PSR-4/PSR-0 映射全部扁平化进 vendor/composer/autoload_classmap.php，跳过文件系统遍历，加载快 2–5 倍。但它只适合「类位置稳定」的环境：
- 生产部署前必须执行（配合
--no-dev） - CI/CD 流水线中构建镜像时固定运行一次
- 本地开发时禁用——每次改
autoload配置或新增类都要重跑，否则新类不生效 - 若项目含大量未声明在
autoload中的“动态 require 文件”，--optimize会直接漏掉它们，导致Class not found
composer.json 里 classmap 和 psr-4 混用的风险
classmap 是硬扫描路径下所有 .php 文件并建映射表，比 PSR 规则更暴力也更确定；但和 PSR-4 共存时容易引发覆盖或冲突：
- 同名类出现在
classmap扫描路径和 PSR-4 命名空间下 → Composer 优先用classmap结果，可能加载旧版本 -
classmap路径包含tests/或examples/→ 无意义地膨胀 classmap 文件，延长 dump 时间 - 推荐做法：仅对「无命名空间、无标准结构」的遗留代码用
classmap（如lib/utils.php），其余全走 PSR-4
PHP 7.4+ 可启用 opcache.preload 加速 autoload（绕过 Composer）
这不是 Composer 功能，但能彻底跳过 autoload 查找逻辑——前提是 PHP 配置允许且项目结构可控：
- 需在
php.ini开启opcache.preload=/path/to/preload.php -
preload.php里用opcache_compile_file()显式预编译核心类文件（如框架入口、常用 service） - 不能 preload 依赖
$_SERVER或运行时配置的文件，否则启动失败 - Composer 的
autoload_files列表可直接挪进 preload 脚本，但要注意加载顺序（trait 必须在 class 前）
实测差异：不同 autoload 策略的 require_once 开销（1000 次调用，PHP 8.2）
用 microtime(true) 测基础加载耗时（排除 opcache 影响）：
| 方式 | 平均耗时（ms） | 备注 | |-------------------------------|----------------|---------------------------------------| | 默认 PSR-4（无优化） | 12.6 | 每次查 vendor/composer/autoload_*.php + 文件系统 | | <code>dump-autoload --optimize</code> | 3.1 | classmap 查表，无 IO | | <code>opcache.preload</code> 启用 | 0.4 | 类已驻留内存，new 时才触发初始化 |
注意：preload 不解决「第一次请求时的类发现」问题，它解决的是「每次请求都重复解析同一堆文件」的问题；而 classmap 优化对 CLI 命令（如 Artisan、Symfony Console）提速最明显——因为 CLI 不共享 opcache。
