容器构建阶段必须用--no-dev--optimize-autoloader--classmap-authoritative三参数组合:--no-dev排除dev依赖减体积,--optimize-autoloader生成扁平classmap,--classmap-authoritative禁用fallback扫描,缺一不可。

容器构建阶段必须用 --no-dev --optimize-autoloader --classmap-authoritative
在 Docker 多阶段构建中,vendor 目录体积直接影响镜像大小和拉取速度。单纯 composer install --no-dev 不够——它只跳过 require-dev 包,但不会压缩已安装包内部的 tests/、docs/、.git 等冗余目录,也不会禁用运行时文件扫描。
真正生效的组合是:
-
--no-dev:排除 phpunit、phpstan 等开发依赖(省下 200–500MB) -
--optimize-autoloader:生成vendor/composer/autoload_classmap.php,扁平化类路径映射 -
--classmap-authoritative:强制 autoloader 只查 classmap,彻底跳过scandir()遍历整个 vendor 目录
注意:这三个参数必须一起用,且只在构建阶段执行——不是线上 composer install,而是在 CI 或 builder 阶段干净环境中运行:
composer install --no-dev --optimize-autoloader --classmap-authoritative --no-interaction
漏掉 --classmap-authoritative 是高频坑点:哪怕你删光了 tests/,autoload 还可能因扫描失败报 Class not found,尤其在只读文件系统或 NFS 挂载环境下。
归档前用 archive.excludes 过滤源码级冗余
archive.excludes 不是给日常 install 用的,而是配合 composer archive 或自定义打包脚本,在解压 dist zip 包时就跳过指定路径——这对容器构建中生成 vendor.tar.gz 特别关键。
在 composer.json 的 config.archive.excludes 中声明:
"archive": {
"excludes": ["/tests/", "/Tests/", "/docs/", "/examples/", "/.github/", "/CHANGELOG.md", "/README.md"]
}
这样每次 composer install 或 composer update 解压 dist 包时,这些路径根本不会落地到 vendor 里。比事后 find vendor -name tests -prune -exec rm -rf {} + 更安全,也避免误删某些包里混在 tests/ 下的运行时示例(如旧版 monolog/monolog 的 handler 示例)。
⚠️ 不要指望 archive.excludes 对 --prefer-source 生效——它只作用于 dist 包解压过程。
语言包和翻译目录得按包名精准剔除
全局删 /translations/ 或 /lang/ 风险极高:有些包(如 symfony/console)把翻译放 Resources/translations/,而 monolog/monolog 的本地化逻辑在 src/Monolog/Translator/;硬删会直接导致 TranslationException 或日志输出乱码。
稳妥做法是用插件 composer-cleaner,并在 extra.cleaner.exclude 中按包声明:
"extra": {
"cleaner": {
"exclude": [
"monolog/monolog:/src/Monolog/Translator/",
"symfony/console:/Resources/translations/",
"laravel/framework:/resources/lang/"
]
}
}
它在 composer install 后自动 unlink() 匹配路径,不碰 autoload 配置,也不改 vendor/autoload.php,所以不会引发类加载失败。
注意:这个插件只清理文件,不处理 vendor/bin/ 下的可执行文件(它们已被 --no-dev 排除),但务必确认没把 vendor/bin/phpunit 这类已被排除的文件夹写进 exclude 列表。
Docker 构建后必须验证 classmap 完整性
容器化部署最易忽略的一环:build 完成后不验证 autoload_classmap.php 是否覆盖全部运行时类。常见现象是某次构建后,php artisan route:list 或 php -m 报 Class not found,但本地开发一切正常。
验证方法很简单:
- 进构建好的镜像:
docker run --rm -it your-image sh - 检查 classmap 是否生成:
ls -l vendor/composer/autoload_classmap.php - 手动触发一次 autoload 检查:
php -d display_errors=1 -r "require 'vendor/autoload.php'; echo 'OK\n';" - 若失败,用
composer dump-autoload --classmap-authoritative --no-dev重生成并对比 diff
真正复杂的地方在于:某些包(如 guzzlehttp/guzzle 7.x)的 PSR-4 映射路径在 classmap 里可能被截断或遗漏,尤其当项目用了自定义 autoload.files 时。这类问题不会在 build 日志里报错,只能靠运行时验证暴露。


















