Composer 怎样优化生产环境的自动加载器

我在 PHP 项目里第一次把“依赖已经装好”和“类加载已经适合生产”分开看，是在一次发布后发现首批请求仍然有不少文件查找。Composer 默认的 PSR-4/PSR-0 规则很方便，但生产环境的类集合在部署时通常已经确定，继续让自动加载器探测文件就多了一层开销。

Composer 官方地址：https://getcomposer.org/

这篇只讨论 dump-autoload 的优化选项。稳妥的起点是 composer dump-autoload --optimize（短写法是 -o），让 Composer 生成 classmap；只有确认项目没有运行时新增类，才考虑 --classmap-authoritative，需要缓存类命中与未命中时再评估 --apcu。

一、先把开发环境和生产环境分开

Composer 官方文档把自动加载优化定位在生产环境：开发时新增或删除类，希望不重建配置也能被 PSR-4 发现；发布时依赖和源码应当是固定的，部署脚本可以在生成 vendor 目录后重建自动加载器。我的经验是，把优化命令放在部署流程里，比把它当成每位开发者的本地默认设置更容易维护。

这里的“优化”不是重新求解依赖，也不是清理 Composer 缓存，而是只改变自动加载器如何从类名找到文件。这样选题边界清楚，出现问题时也知道应该回看哪一步。

二、用 --optimize 生成生产 classmap

--optimize 是 dump-autoload 的生产起点。它会把 PSR-0/PSR-4 规则转换成 classmap，使已知类可以直接落到路径上，减少逐层检查文件系统的机会。Composer 文档也说明，install 和 update 同样支持这个选项；如果部署本来就执行安装，可以直接把它写进安装命令。

# 生产依赖已由 composer.lock 固定，安装时同时生成优化后的自动加载器
composer install --no-dev --optimize-autoloader

# 只重建自动加载器，不重新安装依赖
composer dump-autoload --optimize

也可以在 composer.json 的 config 中设置 optimize-autoloader，但我更倾向于让部署命令显式表达意图：开发者本地执行普通 dump-autoload 时不会意外带上生产假设，发布日志里也能直接看到优化是否被调用。

这一级优化通常是低风险的默认选择。它并不会阻止 PSR-4 回退，因此项目中偶尔出现的未命中类仍可能触发查找；但对正常存在的类，classmap 已经把主要路径固定下来。

三、authoritative classmap 和 APCu 怎么选

如果项目的类在部署后不会动态出现，可以使用 --classmap-authoritative（短写法是 -a）。它会自动包含 classmap 优化，并把 classmap 之外的类直接视为不存在，不再按 PSR-4 继续找文件。这能让未命中也很快返回，但代价是运行时生成的类可能变成生产环境的 class not found。

# 只有确认项目和依赖不会在请求期间生成新类时才使用
composer dump-autoload --classmap-authoritative

另一条路线是 --apcu，它把找到和没找到的类都交给 APCu 缓存；它不会自动生成 classmap，所以通常要和 --optimize 一起考虑。两者不能同时作为 Level 2 方案使用：authoritative 选择“classmap 外不再查找”，APCu 选择“把查找结果缓存起来”，解决的是同一个未命中问题。

# 服务器已启用 APCu，并希望缓存命中与未命中的类查找结果
composer dump-autoload --optimize --apcu

四、把命令接入部署并做最小检查

我的落地顺序通常是先把 --optimize 固定到生产部署，再单独确认项目是否有动态生成类、是否确实提供 APCu。不要为了追求更短的命令就直接上 -a：反射生成代理、运行时拼装类名、某些依赖的特殊加载逻辑，都需要先看清楚。

# 发布阶段生成自动加载器；--no-dev 避免把开发依赖带入生产
composer install --no-dev --optimize-autoloader

# 只检查生成文件是否存在
test -f vendor/autoload.php && echo "autoload ready"

# authoritative 要在测试环境覆盖动态类场景后再启用
composer dump-autoload --classmap-authoritative

最小检查可以围绕三件事：部署命令是否带了正确选项；应用与依赖是否依赖运行时生成类；服务器是否真的有 APCu 并且允许当前 PHP 进程使用。只要其中一项不确定，先停在 --optimize，不要把更激进的策略当成默认答案。

相关问题

开发环境也应该一直使用 --optimize 吗？

通常不建议。开发中新增或删除类的频率更高，把优化放在生产部署更清晰。

--classmap-authoritative 为什么会导致 class not found？

因为 classmap 中没有的类不会再按 PSR-4 规则查找。如果项目或依赖在运行时生成类，就可能超出静态类集合假设。

--apcu 能代替 --optimize 吗？

不能完全代替。APCu 缓存查找结果，但不会自动生成 classmap；生产环境通常先启用 classmap，再根据 APCu 条件决定是否增加缓存。