不能在 docker-compose.yml 的 command 里运行 composer install，因为每次启动容器都会重复执行，浪费时间、破坏镜像缓存，且易因网络或缓存问题导致依赖错误；正确做法是在构建阶段通过 COPY composer.json/composer.lock 后 RUN composer install 完成，并注意扩展、权限、路径和多阶段一致性。
为什么不能在 docker-compose.yml 的 command 里跑 composer install
因为 command 是容器启动时才执行，每次 docker-compose up 都会重新拉取、解包、安装，浪费时间还破坏镜像分层缓存。更糟的是，如果网络失败或 composer.json 变了但缓存没清，你会拿到过期依赖或直接报错。
正确做法是把依赖安装塞进镜像构建阶段，让 Docker 缓存生效。关键点：源码和 composer.lock 必须在 RUN composer install 前就 COPY 进去。
-
COPY composer.json composer.lock ./必须放在RUN composer install之前，且单独成层（不要和COPY . .合并） - 加
--no-dev和--optimize-autoloader参数，生产环境少装、快加载 - 用
composer install --ignore-platform-reqs要谨慎——它绕过 PHP 扩展检查，可能让容器跑不起来
PHP 镜像选 alpine 还是 debian？composer install 行为有啥差别
alpine 镜像小、启动快，但默认没装 openssl、zip 等扩展，composer install 会卡在「cannot load the ionCube Loader」或「failed to open stream: No such file or directory」这类错误里——其实只是缺扩展，不是代码问题。
debian 更稳，但镜像体积大、构建慢。如果你选 alpine，必须显式补全依赖：
RUN apk add --no-cache openssl zip unzip-
RUN docker-php-ext-install openssl zip（注意顺序：先apk add，再docker-php-ext-install） - 别信某些教程的
apk add php-zip—— Alpine 上没有这个包名，只有php7-zip或php8-zip，版本不对就静默失败
如何避免 vendor/ 被 volumes 覆盖掉
本地开发常写 volumes: ["./:/var/www/html"] 把整个项目挂进去，结果容器一启动，宿主机空的 vendor/ 直接覆盖掉镜像里预装好的依赖，composer install 白做了。
解决方法不是删 volume，而是精准排除：
- 用
volumes的:ro或子路径方式，比如./src:/var/www/html/src:ro - 或者在
docker-compose.yml中加volume别名，把vendor/单独映射成只读空目录：vendor:/var/www/html/vendor:ro - 更彻底的：开发时用
docker-compose.override.yml分离配置，构建镜像用无 volume 版本，本地调试再叠加挂载
composer install 在多阶段构建里怎么写才不踩坑
多阶段构建（multi-stage）是最佳实践，但容易漏掉关键步骤：第一阶段装完依赖后，必须 COPY --from=builder /app/vendor /var/www/html/vendor，而不是 COPY --from=builder /app /var/www/html —— 后者会把整个构建上下文（含 node_modules、tests）全拷过去，增大最终镜像。
还要注意路径一致性：
- 第一阶段
WORKDIR /app，第二阶段也得用同样路径做COPY --from，否则路径对不上 - 如果用了
COMPOSER_HOME自定义缓存目录，两阶段要保持一致，否则第二阶段找不到 cache，又重装一遍 -
chown -R www-data:www-data /var/www/html/vendor得跟上，不然 PHP-FPM 会因权限拒绝加载类
最麻烦的其实是 lock 文件更新：改了 composer.json 就得手动删掉旧的 composer.lock 并 composer update，否则构建时用的还是老 lock，CI 里容易误判依赖状态。
