composer autoload 变慢主因是 vendor/autoload.php 加载时的文件扫描与映射构建，尤其在 psr-4 与 classmap 混用或开发依赖过多时；应为稳定第三方库配置 classmap、分离 autoload-dev、生产启用 --optimize-autoloader 和 --classmap-authoritative，并杜绝手动 require_once 干扰自动加载。
依赖多本身不直接拖慢HTTP响应，但会通过几个关键环节间接放大性能损耗——尤其是 autoload 加载、服务提供者注册和配置解析阶段。
autoload 阶段类加载变重
Composer 生成的 vendor/autoload.php 是 Laravel 启动第一道关卡。依赖越多，PSR-4 映射条目越庞大；若未启用优化，每次 class_exists() 或自动加载都会触发目录扫描。实测显示：含 200+ 包的项目，未加 --optimize-autoloader 时，仅加载 autoload 就比优化后慢 300–600ms。
- 必须加
--optimize-autoloader（生产部署标配），它把 PSR-4 转为 classmap 静态数组，跳过运行时遍历 - 检查是否真生效：打开
vendor/autoload.php，确认有require __DIR__ . '/composer/autoload_classmap.php'; - 避免在
composer.json中为非核心包配置冗余 autoload，比如给测试工具加 PSR-4 映射
服务提供者启动时执行耗时操作
很多包（尤其旧版扩展、注解驱动工具、配置扫描器）会在 register() 或 boot() 里做文件遍历、反射分析或 YAML 解析。这些操作在 CLI 下被 xdebug 放大后更明显。
- 临时禁用 xdebug 测试真实开销：
php -d zend_extension= -d xdebug.mode=off -r "require 'vendor/autoload.php';" - 用
strace -e trace=openat,stat,read php -r "require 'vendor/autoload.php';"查看它打开了哪些路径——常发现某包在递归扫config/或src/ - 用
composer depends vendor/package-name看谁拉进了这个重型依赖，再评估是否可替换或隔离
composer.lock 文件膨胀影响解析稳定性
大型项目 lock 文件超 10MB 很常见，里面存了每个包的完整元数据（dist hash、source commit、dev 依赖列表等）。虽然 install 不解析依赖，但读取和校验这个大 JSON 仍占 CPU 和内存。
- 定期运行
composer update --lock压缩格式、去重字段 - 清理长期不用的
require-dev，它们不安装但仍参与 lock 文件构建 - 私有包加
"archive": {"exclude": ["/tests", "/docs"]}，避免无用路径计入 hash
CI/CD 中误用 update 替代 install
这是最隐蔽也最普遍的陷阱：本该用 composer install（按 lock 文件直装），却写成 composer update。后者要重跑 SAT 求解器，对复杂依赖树可能耗时数分钟，且 CPU 占满。
- 生产部署脚本、Dockerfile、CI 流水线中，只允许
install，严禁update - 确保
composer.lock已提交到仓库，且与composer.json版本一致 - CI 中加
--no-interaction --no-progress --prefer-dist --no-dev，砍掉所有非必要环节
