Composer不管理Docker镜像，仅负责生成vendor/；必须用与运行时一致的PHP镜像（如php:8.2-cli）在构建阶段执行composer install --no-dev --no-scripts --optimize-autoloader，禁用运行时无关操作并确保autoload路径一致。
composer 本身不管理 Docker 镜像，它只管 PHP 依赖。所谓“用 Composer 管理镜像”，是常见误解——镜像构建、分层、运行时环境这些事，得靠 Dockerfile 和构建流程控制，composer 只在其中负责一个环节：生成正确的 vendor/。
为什么不能直接在容器里跑 composer install 作为主命令？
这不是语法错误，而是部署模型错位。容器启动时执行 composer install 会带来三个硬伤：
- 每次
docker run都重装依赖，网络失败、超时、平台检查失败全在运行时暴露，不可控 -
vendor/写入挂载卷后权限混乱（宿主机 UID ≠ 容器 UID），导致Class not found或Permission denied - 构建缓存失效：Docker 无法对
RUN composer install做分层复用，哪怕只改一行代码，整个依赖树重拉
Dockerfile 里该用哪个 PHP 镜像执行 composer install？
必须和最终运行时镜像的 PHP 主版本、SAPI 类型、关键扩展完全一致。例如：
- 你的应用最终跑在
php:8.2-fpm上 → 构建阶段就得用php:8.2-cli（同源基础镜像） - 别用
composer/composer:2-bin独立镜像执行 install —— 它没有ext-redis、ext-mbstring，composer.lock中的platform字段会记录错误的扩展可用状态 - Alpine 镜像要额外
RUN apk add --no-cache curl unzip openssl ca-certificates，否则静默失败
composer install 在构建阶段必须带哪几个参数？
生产环境构建中，这三个参数缺一不可，省掉任何一个都可能让镜像上线即崩：
-
--no-dev：跳过require-dev，避免 PHPUnit、PHPStan 进入运行时镜像 -
--no-scripts：禁用post-install-cmd等钩子——它们常调npm、写缓存、依赖宿主机工具，在构建阶段既不可靠也无必要 -
--optimize-autoloader（或-o）：生成静态类映射，否则首次请求触发慢 autoload，Nginx 超时或 Laravel 黑屏
顺带一提：--ignore-platform-reqs 是临时调试开关，绝不能进生产 Dockerfile —— 它会让 ext-redis 缺失也不报错，等容器跑起来才 Fatal error。
开发时怎么让 vendor/ 支持热更新又不破坏构建一致性？
核心原则：构建阶段生成 vendor/，开发时只挂载源码，不挂载 vendor/。真实可行路径只有两条：
- 多阶段构建中，
COPY --from=builder /app/vendor ./vendor到最终镜像；运行时只-v $(pwd)/src:/app/src，PHP 自动加载仍走镜像内已优化的vendor/ - 若真需动态改依赖（如 CI 临时调试），启动容器时强制指定 UID：
docker run -u $(id -u):$(id -g) -v $(pwd):/app php:8.2-cli composer require monolog/monolog，并确保宿主机composer.json已提交、composer.lock同步更新
最容易被忽略的一点：所有构建阶段的 WORKDIR 必须和 autoload 配置里的路径一致，否则 vendor/autoload.php 加载失败，连 composer dump-autoload -o 都救不回来。
