Composer本身不执行导出，导出慢的根源在运行时代码（如N+1查询、内存限制、模板渲染等），而非composer.json配置；真正有效的Composer相关项仅间接起效，如全局镜像、optimize-autoloader等。
Composer 本身不执行“导出”——它不渲染 Excel、不生成 PDF、不打包 ZIP 文件。如果你的项目里有“导出慢”，问题一定在运行时代码里，不是 composer.json 或 composer install 配置能解决的。
但现实中，很多人把「导出逻辑所在的包」和「Composer 管理这个包的方式」混为一谈。下面直说关键点：哪些配置真有用，哪些纯属误导。
为什么改 composer.json 不能加速导出
导出性能卡点从来不在依赖安装环节，而在运行时：
- 数据查库时没加索引，或用了 N+1 查询
- 导出类（如
Maatwebsite\Excel\Excel）在循环中反复 new 实例或调用save() - 模板渲染用了 Blade 嵌套 + 大量
@foreach，且未启用缓存 - 队列任务用了 database 驱动，表锁严重；或 Redis 连接池太小，排队等连接
- PHP 内存限制太低（
memory_limit=128M），大文件直接 OOM
composer.json 里的 autoload、scripts、repositories 全都不参与这些环节。改了也没用。
--prefer-dist 加速的是安装，不是导出
这个参数只影响 composer install 时怎么拉包：
- 对已打 tag 的公开包（如
laravel/framework），--prefer-dist会下载 zip 包，比 git clone 快 3–5 倍 - 但它对
dev-master、dev-develop或未打 tag 的私有包完全无效，Composer 只能 fallback 到 source - 即使你加了
--prefer-dist，如果composer.lock里记录的是 source 方式，它也不会重试 dist —— 必须删 lock 后重装 - 导出功能是否快，和 vendor 里是 zip 解压还是 git clone 出来的，毫无关系
验证是否生效：跑 composer install -vvv | grep "Downloading.*zip"，看到镜像源域名（如 mirrors.aliyun.com/composer/dist/）才算真走 dist。
真正该配的 Composer 相关项（只间接起效）
这些配置不加速导出本身，但能避免导出失败或拖慢部署流程：
- 全局镜像必须三要素齐全：
repo.packagist（单数）、type: "composer"、URL 以https://开头且末尾带/；缺一个就静默回退官方源 -
"optimize-autoloader": true（或加-o）可减少类加载开销，对高频调用导出类的 CLI 命令略有帮助，但对 Web 请求几乎无感 -
"classmap-authoritative": true（或加-a）能加快自动加载，但若导出逻辑用了动态类名（如new $className），可能报错 - CI/CD 中挂载
~/.composer/cache到容器内，避免重复下载，尤其适合多项目共享环境
注意："apcu-autoloader": true 要求 APCu 扩展启用，且只缓存类映射结果，不缓存导出过程中的数据或 IO。
导出慢？先确认你用的是哪个方案
不同导出库瓶颈差异极大，别统一优化：
- Laravel Excel：检查是否用了
WithChunkReading+WithBatchInserts，避免全量 load 到内存 - Spatie Export：确认
ShouldQueue是否正确实现，队列驱动是否匹配（Redis > database） - 原生
fputcsv/XMLWriter：重点看 buffer 是否 flush、是否用了ob_start()、是否有意外的var_dump - Blade 渲染 HTML 后转 PDF（如 Dompdf）：禁用远程字体、压缩 CSS、预加载图片 base64
composer 的角色只是把上述库装进来——它不决定你怎么用，也不替你写 foreach 循环。
导出逻辑越复杂，越容易忽略 PHP 进程本身的限制：比如 max_execution_time 被设成 30 秒，或 opcache.revalidate_freq 太低导致每次请求都 reload 类文件。这些跟 Composer 没半毛钱关系，但会直接让导出失败。
