Composer 不应在容器中长期运行或作为服务部署，它仅是 PHP 依赖管理工具；正确做法是在构建阶段用生产一致环境执行 composer install --no-dev --no-scripts --optimize-autoloader，并通过多阶段构建分离依赖安装与运行环境。
Composer 不能也不该在 Docker 容器里“长期运行”或“作为服务部署”——它只是 PHP 的依赖管理工具，不是运行时组件。你在容器里真正需要的，是“如何在构建镜像时正确安装依赖”，以及“如何避免把 vendor 目录和 composer.lock 丢进镜像却导致环境不一致”。
为什么不能直接 docker run --rm -v $(pwd):/app composer install？
这命令看似简单，但会踩三个坑：
- 宿主机的
composer.lock文件权限或换行符可能被挂载后破坏（尤其 Windows/macOS 开发机 + Linux 容器） - 容器内 PHP 版本、扩展（如
ext-zip、ext-openssl）和你最终应用镜像不一致，composer install成功，但运行时报错 - 挂载本地
vendor进容器，会覆盖镜像里预构建的优化层，CI/CD 构建缓存失效，每次重装依赖
Dockerfile 中正确的 composer install 写法
核心原则：在构建阶段用和生产一致的 PHP 环境安装依赖，且不保留 dev-only 包。
- 用多阶段构建，第一阶段只装依赖，第二阶段只复制
vendor和代码 - 必须指定
--no-dev --no-scripts --optimize-autoloader，否则 CI 构建慢、镜像大、启动慢 - 确保
composer.lock和composer.json在 COPY 到构建上下文的**最早阶段**，否则缓存失效 - PHP 基础镜像要带
curl和unzip（比如php:8.2-cli-slim不自带，得自己apt-get update && apt-get install -y curl unzip）
FROM php:8.2-cli-slim RUN apt-get update && apt-get install -y curl unzip COPY composer.json composer.lock ./ RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer RUN composer install --no-dev --no-scripts --optimize-autoloader <p>FROM php:8.2-apache COPY --from=0 /app/vendor /var/www/html/vendor COPY . /var/www/html
本地开发时怎么快速重装依赖又不污染镜像？
别在容器里跑 composer install，改用 docker build 触发重新安装 —— 但前提是让构建感知到 composer.lock 变了。
- 在
Dockerfile中，把COPY composer.json composer.lock ./放在最前面，早于其他文件 - 这样只要
composer.lock变，后续所有 layer 缓存失效，强制重装 - 如果只想临时调试（比如加个
require-dev），用docker run --rm -v $(pwd):/app -w /app php:8.2-cli composer install --no-interaction，但仅限本地，绝不提交到 CI - 注意：这个临时命令里的 PHP 镜像版本必须和你的基础镜像一致，否则
opcache.preload或ext-intl版本差异会导致线上报错
最常被忽略的一点：很多团队把 composer install 放在 ENTRYPOINT 脚本里，每次容器启动都执行——这不仅慢，还会因网络波动失败、写坏 vendor 权限、甚至把 dev 包带到生产。构建时做，就完了。
