不能在容器启动时执行 composer install，因php扩展缺失或版本不一致会导致失败或装入不兼容包；应于dockerfile构建阶段安装，并用多阶段构建复用vendor，同时通过config.platform.php锁定php版本确保环境一致。
为什么不能在 Docker 容器里直接 composer install？
因为容器启动时 PHP 扩展、扩展版本、ext-zip 或 ext-opcache 缺失，composer install 会失败或装出不兼容的包。更常见的是：宿主机和容器内 php -v 或 php --ini 输出不同，导致 composer.lock 生成环境与运行环境不一致。
实操建议：
- 永远在构建镜像阶段执行
composer install，而不是在docker run时临时执行 - 确保
Dockerfile中安装了所有composer运行依赖（如unzip、git）和 PHP 扩展（ext-zip、ext-xml、ext-mbstring） - 用
--no-dev --optimize-autoloader --classmap-authoritative参数，避免把开发依赖打进生产镜像
composer install 报错 “Could not open input file: composer.phar” 怎么办？
这是最常被忽略的路径问题：你没把 composer 可执行文件放进 $PATH，或者用了错误的安装方式（比如只下载了 composer.phar 却没设为可执行或没软链）。
实操建议：
- 在
Dockerfile中用官方推荐方式安装：curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
- 检查是否真能执行：
composer --version必须在RUN阶段就成功返回 - 别用
php composer.phar install—— 容器里没php命令或路径不对时，这行命令比composer install更容易静默失败
如何让 vendor/ 不进镜像又不影响运行？
不能靠 .dockerignore 忽略 vendor/ 后再 composer install —— 那样构建时根本没 vendor/，PHP 一启动就报 Class not found。真正的解法是分层构建 + 复用已安装的 vendor。
实操建议：
- 用多阶段构建：第一阶段用完整 PHP 环境跑
composer install，把vendor/复制到第二阶段精简镜像中 - 别挂载
vendor/作为 volume —— 宿主机和容器 PHP 版本稍有差异，opcache或apcu就可能拒绝加载缓存后的类 - 如果必须热重载代码（比如本地开发），用
bind mount整个项目目录，但明确排除vendor/和composer.lock，防止覆盖容器内已安装的依赖
PHP 版本不一致导致 composer install 成功但运行时报错
典型现象：composer install 在 PHP 8.2 下通过，但容器用 PHP 8.1 启动时抛出 ParseError: syntax error, unexpected token "readonly" —— 因为 composer.lock 记录的是 8.2 兼容的包版本，而某些包的高版本已弃用 8.1。
实操建议：
- 在
composer.json的config.platform.php显式声明目标 PHP 版本："config": { "platform": { "php": "8.1.28" } } - CI/CD 流水线里，用和容器完全一致的 PHP 版本生成
composer.lock，而不是开发者本地的版本 - 检查
composer show --platform输出，确认它和容器内php -v一致；否则composer install会悄悄降级或跳过某些约束
最麻烦的不是命令写不对，而是 composer.lock 生成环境和容器 PHP 环境之间那半个小版本的偏差——它不会报错，只会等你上线后某个凌晨三点抛出一个找不到的类。
